Re: address@hidden: Font Lock on-the-fly misfontification in C++]

[Alan Mackenzie]

Hi, Simon; Hi, Richard!

On Wed, Jul 19, 2006 at 10:22:00PM -0400, Richard Stallman wrote:
> Please DTRT.

> ------- Start of forwarded message -------
> From: "Marshall, Simon" <address@hidden>
> To: "'Emacs Pretest Bug (address@hidden)'"
>       <address@hidden>
> Date: Wed, 19 Jul 2006 16:46:04 +0100
> MIME-Version: 1.0
> Content-Type: text/plain
> Subject: Font Lock on-the-fly misfontification in C++
> X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
>       version=3.0.4

> Put the following in a fubar.cpp:

> class Fubar :
>   public Foo, // Foo fontified as a type, at first
>   public Bar  // Bar fontified as a type, at first
> {
>   Foo bar(Snafu snafu,        // Types, function, variable fontified, at first
>         Foo foo,
>         Bar bar);
>   Foo bar(Snafu *snafu,       // Types, function, variable fontified, at first
>         Foo foo,
>         Bar bar);
> };

> Then emacs -Q fubar.cpp.  I see Foo, Bar and Snafu fontified as types
> even where declaring functions and variables.  The corresponding
> functions and variables are fontified correctly.  This is great!

> Then do the following.

> 1.  Append a space to the first (or second) commented line.  Bug:
> fontification of Foo (or Bar) is removed from that line.

> 2.  Append a space to the third commented line.  Bug: fontification of Foo
> and bar is removed from that line.

> 3.  Append a space to the fourth commented line.  Bug: fontification of Foo,
> bar, Snafu and snafu is removed from that line.

The problem is that after a textual change, the changed line gets
fontified as an atomic entity, i.e. yanked out of its context.  The
solution is to determine the bounds of the region to fontify by analysing
the surrounding text syntactically.  (Sorry about the number of big words
in that sentence.)  Such a determination would, in these cases, identify
exactly the comments on these lines.

There is a lot of work to be done here in CC Mode, and possibly some
enhancements are still needed in Font Lock.  I'm hoping to do the CC Mode
bit for release 5.32 (the current release is 5.31.3) within a year or
two.  In the meantime, a workaround is M-o M-o,
`font-lock-fontify-block'.

> Somewhat spookily, if you then repeat (2), then the fourth commented line
> (3) gets fontified correctly after the deferral delay.

Yes.  Changing the "public Bar" line marks all subsequent text for
deferred fontification.  This latter is done in the full syntactic
context.  Yes, it's disconcerting.

> I think this is some sort of problem with Jit Lock mode multiline
> fontification, at least for (2) and (3), since Lazy Lock mode works ok.

Isn't Lazy Lock obsolete in Emacs 22?

-- 
Alan Mackenzie (Munich, Germany)