Re: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]

[Stefan Monnier <monnier@iro.umontreal.ca>]

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


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642