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

[Ralf Angeli]

* Stefan Monnier (2006-02-13) writes:

>> Currently a function is used as matcher in `font-lock-keywords' for
>> this functionality.  It basically operates like this:
>
>>   (catch 'match
>>     (while (re-search-forward "<<" limit t)
>>       (let ((beg (match-beginning 0)))
>>       (search-forward ">>" limit 'move)
>>       (store-match-data (list beg (point)))
>>       (throw 'match t))))

Ouch.  Pasting the code into a wterm messed up indentation pretty
badly. )c:

> I.e. equivalent to "<<\\(.\\|\n\\)*?\\(>>\\)?".

The function actually used in AUCTeX does a bit more.  For example it
checks if a face for verbatim content is present and does not set a
match in such a case.

>> With the matcher function above text in quotation marks won't be
>> fontified when I start typing stuff like "<<foo" as long as there is
>> no closing quotation mark.  Now if the closing quotation mark is
>> entered a few lines below the line containing the opening quotation
>> mark, font locking won't see the opening quotation mark and the
>> multiline quotation won't be fontified.
>
> Indeed.  You can use contextual refontification, tho:
>
>    (if jit-lock-context-unfontify-pos
>        (setq jit-lock-context-unfontify-pos
>              (min jit-lock-context-unfontify-pos
>                   (re-search-backward "<<" limit t))))
>
> it's specific to jit-lock, tho.

Hm, I would not like leaving people who disabled jit-lock out in the
cold.  So the hook is probably a better alternative.  But thanks for
that hint anyway.

> Also it will not refontify immediately but only after jit-lock-contex-time.
> I'd consider it a feature, but others may disagree.

I am tempted to disagree but maybe this is a case of getting used to it.

> I like the idea behind your before-font-lock-after-change-function, except

Uh, Alan Mackenzie is the originator of this proposal, not me. (c:

> that I'd want it to be in font-lock-default-fontify-region.  I.e. it should
> then be possible to remove mention of font-lock-multiline from
> font-lock-default-fontify-region by moving it to this new hook (which we
> could call font-lock-fontify-extend-region-functions).

Hm, how would it be possible to detect closing tags in this case?
Maybe with an initial search for these tags across the region to be
fontified.  Or on a case by case basis for every closing tag which is
encountered during fontication of the region?  This would be rather
inefficient compared to using a hook to be called before
`font-lock-after-change-function'.  But maybe you are thinking about
something completely different.

-- 
Ralf