Re: Probable bug in font-lock-mode.

[Thaddeus L. Olczyk]

On Thu, 27 Dec 2001 03:30:21 GMT, Brian P Templeton <bpt@tunes.org>
wrote:

>olczyk@interaccess.com (Thaddeus L. Olczyk) writes:
>
>> I want to see if anyone else is experiencing this bug before I submit
>> it. Part of the problem is that I can't isolate it deterministically.
>> This is because I have to wait for the automatic refontify 
>> ( I'm sorry, I don't know what it is called. ) to happen to see it.
>M-x font-lock-fontify-buffer
>> What parts I can automate I will and maybe someone can
>> The steps are
>> 1) Decompress the zip file into some area. ( Sidenote: sorry for 
>>     attaching a zip file, but it is only 1K. )
>A bzip2ed tarball is attached for the convenience of Unix users and to
>not require proprietary software to decompress the file.
Oops. Sorry I meant to send it as tar.gzip.

>I think the problem is that the standard C++ comment matcher is a
>regexp similar to
>
>    /\\*.*\\*/
/[*]\\([^*]\\|[*][^/]\\)[*]/ would be more likely but I don't believe
it.

>and you need to change it to match /*...*/ without // anywhere between
>the /* and */.
Having stepped through some of the font-lock mode, I don't believe
that it works that way. It probably uses syntax tables and does some
basic character matching. Unfortunately the code is hard to step
through a debugger ( and would be so even if elisp had a halfway
decent debugger ). I do however think that it is a battle between
standard comments and comments added via font-lock-add-keyword.


>> The version of Emacs I am using is: 21.1.1. I'm doing this on NT, but
>> I would be interested if people on other OSs see the same problem.
>I see it too, on Unix (specifically, GNU/Linux; my distribution is
>Debian, version 2.2, with Emacs 21.1.1). I also tested it with Emacs
>20.7, and the problem also appears there.
I've downloaded xemacs and will be trying it there.