[Top][All Lists]

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

Re: `font-lock-extend-region-functions' vs. `font-lock-extend-after-chan

From: Stefan Monnier
Subject: Re: `font-lock-extend-region-functions' vs. `font-lock-extend-after-change-region-function'
Date: Wed, 29 Apr 2009 16:26:38 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

>> > But the new region that EXTEND is called with begins at 523, and not 701
>> > even though we processed the region between 523 and 701 already.
>> > This seems more inefficient than it needs to be if I'm not missing
>> > anything.
>> You're not missing anything.  It's an inefficiency in jit-lock, indeed.
>> jit-lock asks font-lock to highlight 1-523 and font-lock has no way to
>> tell jit-lock that the first call already highlighted 1-701, so next
>> time jit-lock needs highlighting it will do 523-1034 because it doesn't
>> know that 523-701 was done already.
> Is this intended to be fixed? For example, the extending of the
> font-lock region could be made a seperate step which
> `jit-lock-fontify-now' has to run explicitly.

Yes.  This problem was introduced in Emacs-22 but at the time I decided
it was better to "keep it that way for now" (the freeze was coming) and
fix it for Emacs-23, but I never got around to do it.

The way I imagine fixing it is by changing jit-lock-functions such that
the functions on that hook (e.g. font-lock-fontify-region) would return
the new boundaries they used (or nil if they kept the boundaries passed
by jit-lock).


reply via email to

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