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

[Stefan Monnier]

>> >> 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

>> If you placed a font-lock-multiline property on the whole thing,
>> font-lock would know not to yank that one line out of its context.

> We've already been through this at some length.

> I think we're agreed that it's not possible to put this property exactly
> where it's needed (at the boundaries of the region to fontify, and
> nowhere else) when it's needed (at the time of the change, before Font
> Lock starts fontifying).

I'm talking about this specific example, which is about refontification, not
about the original fontification.  As you know, the two problems are
closely related yet separate.

>> > solution is to determine the bounds of the region to fontify by
>> > analysing the surrounding text syntactically.

>> Presumably, at the moment when Emacs fontified it correctly, it knew
>> the corresponding bounds, so it could have added the
>> font-lock-multiline property at that time, thus avoiding the need to
>> re-determine those bounds later when refontifying.

> The buffer was originally fontified as a whole, thus the corresponding
> bounds were BOB and EOB.

Is that what is called a strawman argument?
Come on, be more constructive, please.
In the pattern rules where you add the correct highlighting, you probably
have a pretty good idea about where the relevant boundaries are.

Have you taken the time to look at my cc-awk.el patch example (I mean,
other than to try and find some superficial flaw in it).  It should give you
a pretty good idea of what the above paragraph refers to.

Check also my sample patch for problems number 2 and 3 for another example.

> When the buffer is changed, in the most general case, the bounds of the
> region to be refontified are going to have to be recalculated before
> fontifying.

You keep saying that, but that's not the case.  When *re*fontifying, you
don't need to recalculate those context bounds, as long as you were
careful to store them (e.g. in a font-lock-multiline property) when you
knew them.

> As you are aware, I intensely dislike the notion that an entire buffer
> should have to be left constantly marked with all places where it
> fontification might have to straddle line boundaries, rather than
> determining these things as they are needed.

That's OK: your likes an dislikes only bother you.  BTW the entire buffer
already needs to be left constantly marked with face information (takes
a lot more resources) as well as `fontified' information.
Try C-u C-x = a few times to get an idea.

> I also dislike being unable to specify an exact fontification region to
> Font Lock (such as the bounds of one of Simon's comments).

I don't understand what you're referring to.


        Stefan