[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `font-lock-extend-region-functions' vs. `font-lock-extend-after-chan
Re: `font-lock-extend-region-functions' vs. `font-lock-extend-after-change-region-function'
Wed, 29 Apr 2009 16:26:38 -0400
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