emacs-devel
[Top][All Lists]
Advanced

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

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


From: Ralf Angeli
Subject: Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
Date: Wed, 15 Feb 2006 22:42:02 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

* Alan Mackenzie (2006-02-15) writes:

> On Sun, 12 Feb 2006, Stefan Monnier wrote:
>
>>.... 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.
>
> I strongly oppose such a change.  With that change:
>
> (i) font-lock-fontify-region would no longer be fontifying the region
> specified by its paramters, but a different (possibly larger) one. 
> (ii) the hook function (which recalculates BEG and END) might well refer
> to variables set by a before-change-functions hook.  (This is done in AWK
> mode, for example).  f-l-f-region is regularly called when there is no
> buffer change in progress.
>
> Both of these things would make debugging a hook function much more
> difficult than it already is.  Determining the region to fontify and
> actually fontifying it are two logically distinct operations.  They
> shouldn't be intermingled with eachother.

This is all well and good, but in contrast to the after-change hook, a
hook in `font-lock-default-fontify-region' could not only adjust the
region after a change but also during fontification by chunks as done
by jit-lock.  (That's an advantage I haven't noticed before.)
Following your reasoning of separating the determination of the region
to be fontified from the fontification itself would require that
jit-lock determines the chunks to be fontified more intelligently.

-- 
Ralf




reply via email to

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