[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: Alan Mackenzie
Subject: Re: address@hidden: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]
Date: Thu, 16 Feb 2006 11:20:47 +0000 (GMT)

Hi, Ralf!

On Wed, 5 Feb 2006, Ralf Angeli wrote:

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

That is horrible.  f-l-d-f-r currently fontifies the region requested by
the caller, not a different region that Font Lock finds more convenient.
If we change its functionality, something somewhere will surely break.

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

I don't follow that.  There are several different ways that jit-lock
determines its chunks.  There's after-change, after-scrolling, stealth,
at least.  I don't see why determining a jit-lock after-change region
need have anything to do with determining an after-scrolling or stealth



reply via email to

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