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?

I can't find this patch any more.  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.

> The reason I am asking this is that I am currently wrecking my brain
> about how to make font locking for LaTeX buffers controlled by AUCTeX
> more robust.  On a regular basis we are getting reports about font
> locking of multiline constructs failing, thereby spilling color all
> over the buffer and/or slowing down editing quite severly.  (We are
> using `font-lock-multiline' for fontification of multiline
> constructs.)  This mainly happens with text which is erroneously
> identified as the start of a multiline construct but has no matching
> closing tag.  The last report we got was about "<<" which can be an
> opening quotation mark but which may also be used unmatched in some
> math constructs.

> An idea for making font locking more robust in this respect might be
> to desist from coloring the rest of the buffer in case of an unmatched
> opening tag, i.e. to leave it alone if a matching closing tag cannot
> be found in an arbitrarily large region after the opening tag.  That
> would mean fontification will only be applied as soon as the closing
> tag is typed.  For that to work, however, I'd have to look backwards
> for an opening tag which could be done with a hook like the one
> proposed above.

I'm not sure how that relates to before-font-lock-after-change-function.
Could you describe how you currently font-lock those <<...>> multiline
elements and how you'd use before-font-lock-after-change-function to solve
the problem?


        Stefan