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

[Stefan Monnier]

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


        Stefan