Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[Stefan Monnier]

>>>> This patch to font-lock is exactly the sort of change I was thinking of.
>>>> Could someone please install it, then rename
>>>> before-font-lock-after-change-function to
>>>> font-lock-extend-region-function, and rename
>>>> font-lock-run-before-after-change-hook to font-lock-extend-region?

>> .... Based on the name, I suppose it's some kind of hook in
>> font-lock-after-change-function, in which case I'd be tempted to suggest
>> to move it to font-lock-fontify-region instead, to reduce the
>> performance impact and make it easier to deal with lazy-lock&jit-lock
>> since these tend to use their own after-change-function.

> I strongly oppose such a change.  With that change:

> (i) font-lock-fontify-region would no longer be fontifying the region
> specified by its paramters, but a different (possibly larger) one.

That's already the case since font-lock-fontify-region will typically not
fontify from BEG to END from the beginning of line before BEG to the end of
line after END.  Then that can be extended yet further because of
font-lock-multiline.  Nobody has ever complained about this.

So why is it a problem?

> (ii) the hook function (which recalculates BEG and END) might well refer
> to variables set by a before-change-functions hook.  (This is done in AWK
> mode, for example).

Which variables would that be?

> f-l-f-region is regularly called when there is no buffer change in progress.

Indeed.  Again, why is it a problem?

> Both of these things would make debugging a hook function much more
> difficult than it already is.  Determining the region to fontify and
> actually fontifying it are two logically distinct operations.

With jit-lock, the region to fontify is not determined by the
after-change-functions either.


        Stefan