[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 16:08:10 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> Huh?  Why would window-start matter?

> Because fontification triggered by redisplay will fontify the displayed
> area first.  `jit-lock-context-fontify' would reset the fontified
> property for everything after the "<<".  Redisplay now would trigger
> refontification below window-start.  It won't care about the "<<".

Good point.  Later fontification (e.g. stealth) may pay attention to the <<
at some point, tho it won't refontify the parts that were already fontified.

>> I'm not sure which hook you're talking about.  The code I wrote above is
>> meant to be used on font-lock-keywords when finding a ">>".

> The hook that would trigger searching for the "<<" after a buffer
> change, `before-font-lock-after-change-function' or whatever it will be
> called.  I simply believe that searching some 1000 characters every time
> you type one single character may slow down editing noticeably.  But
> maybe I didn't understand the scenario correctly.

Yes, there's a misunderstanding: my 4 lines of code were meant to be used
*instead of* before-font-lock-after-change-function (i.e. placed on

And yes, I agree about the speed penalty which is why I want to run such
a hook in font-lock-default-fontify-region rather than in

Note, tho, that the 1000-byte search would probably only only happen when
the line has a ">>" on it.  And it's all very much fast enough for
self-insert-command.  The problem is much more severe when you're running
a command that does many buffer modification and thus runs the hook
many times without intervening user interaction.


reply via email to

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