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

[Ralf Angeli <angeli@iwi.uni-sb.de>]

The quoted message is from a discussion back in last March regarding
the addition of a hook for extending backwards the region to be
fontified with a hook to be called before
`font-lock-after-change-function'.

* Richard Stallman (2005-03-11) writes:

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

Apparently the hook hasn't been added yet.  Is it still planned to add
it?

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.

-- 
Ralf