Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Stefan Monnier]

>> It changes the overall behavior a bit, yes.  And of course, that might
>> trigger bugs somewhere, like any other change.  But other than that, it
>> should not change the actual final result other than how fast we get to
>> it, no.
>
> I'm looking at this from the POV of someone who writes a function to
> be registered with JIT font-lock.  They need to understand these
> details to be able to write code which will do what they want.

Why should they?  The function is asked to handle region BEG...END and
it may elect to handle a larger region.  For efficiency reasons, most
such function will extend the BEG...END region as little as possible, so
they don't really have much choice in terms of which part of the buffer
to handle: as small as possible, yet larger or equal to BEG...END.

As for the value those functions return, it can always be nil unless
they elect to tell jit-lock about that larger region they decided to
handle in which case jit-lock will try and take advantage of that info
to avoid redundant work.

This description has been valid for a while and the changes discussed
here do not impact it at all.

> They would still know about the automatic ordering because if some
> other function gets put at the first place, the results will be
> different, and that needs to be explained.

I don't see in what sense "the results will be different".
Which results are you talking a bout?  What kind of difference do you foresee?


        Stefan