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

[Alan Mackenzie]

Hi, Ralf!

On Sun, 12 Feb 2006, Ralf Angeli wrote:

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

Why don't you construct a regular expression which would only find a "<<"
which isn't in a maths construct?  I don't know LaTex, but assuming these
"<<" ">>" pairs can't be nested (is this the case?), you could make this
regexp stop (with "not found") at a second "<<" (not within a maths
thingy).

In your font-lock matcher function, you would first go back to a "safe
place", then scan forward for this regexp.  Even though the regexp would
be quite intricate, it would still be reasonably fast, even if you end up
scanning to the end of the buffer.

Another idea would be to maintain a list of "<<" ">>" pairs, which
you would update in an after-change-function.

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

I suggest that you font lock only the complete construct "<< ..... >>".
You might want to give an unmated "<<" or ">>" font-lock-warning-face
until the user completes the construct.

>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

-- 
Alan Mackenzie (Munich, Germany)