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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Sat, 04 Sep 2021 11:55:08 -0400
> 
> >> But my understanding of what you're saying is that you don't consider
> >> "how `jit-lock-bounds` are used" to be an internal detail.  Instead you
> >> consider these to be part of the "protocol" that the writer of client
> >> functions needs to know in order for those functions to work correctly.
> >> And I can't understand why you'd think that.  I think even in the
> >> current situation, none of what we have discussed has prompted a need or
> >> desire to change client functions: they're oblivious to the change
> >> being discussed.
> > We have the reason right before our eyes: what Alan needs to do.  If
> > these details are not important, why does he work on changing them?
> 
> His change is not to font-lock but to jit-lock.  So it's consistent with
> my claim that it's a matter that's internal to jit-lock.
> 
> >> If so, could you give some kind of scenario where that could happen?
> > Why do I need to come up with a scenario, when it's clear as a day
> > that programming blindly to an insufficiently documented interface is
> > asking for trouble?
> 
> But the change under consideration does not affect the documentation of
> the API exposed to client functions, AFAICT.  I'm not asking the author
> to program blindly.  I just can't see any reason to specify any more
> precisely than saying that BEG...END can be any valid region in the
> buffer and that the function can use `jit-lock-bounds` to inform
> jit-lock of the region actually handled, where this `jit-lock-bounds`
> needs to cover BEG...END but is otherwise optional and only used for
> optimization purposes.
> 
> [ This is largely consistent with what you wrote in the docstring, so
>   it seems we agree on this part.  ]
> 
> The precise way in which jit-lock uses this info for optimization
> purposes is something that may change (and hence should not be part of
> the contract/documentation) as evidenced by the fact that Alan already
> has 2 proposed patches that change it in different ways, and I myself
> described yet another possible way it could be used.

Let's agree to disagree about this, okay?