[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: C++-mode: Syntax highlighting: wrong color for funct

From: Stefan Monnier
Subject: Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
Date: Tue, 14 Feb 2006 14:05:38 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

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

Sure.  Also it's more efficient than the above regexp.

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

jit-lock is already needed for correct refontification of multi-line
comments and strings, so I wouldn't worry too much about the effect it would
have of foncitifcation of other multiline constructs.

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

Huh?  I must be missing something: I don't see what's different between
font-lock-after-change-function and font-lock-default-fontify-region, other
than the fact that they're called at different moments.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]