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 10:44:43 -0400
> 
> I still can't see in which way the specific details of how jit-lock
> chooses the BEG...END arguments and uses the returned `jit-lock-bounds`
> affects the authors of client functions.
> 
> > I really don't understand why we are having this conversation.  It's
> > almost as if you claimed that documenting non-trivial behavior is a
> > bad idea, or a luxury.  But you cannot be seriously thinking that.
> 
> I think it's a bad idea to document internal details, yes.
> Those who need to know those details can look at the code.
> 
> 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?

> The only part where it might be visible is in a new argument to
> `jit-lock-register` that would specify whether a client function would
> like to come first or not.

That's one thing to be documented (if being the first is indeed
important).  And you cannot explain that without telling something
about how this stuff works.

> > Excuse me, but the jit-lock-bounds was almost completely undocumented,
> > until I did that a few days ago.  So what description are you alluding
> > to which has been valid?
> 
> The implicit one that comes from the range of ways those client
> functions could be called in the past and how their return value could
> be used.

According to Aristotle's logic, you can tell anything you want about a
non-existing thing, and no one will be able to prove you wrong.

> >> I don't see in what sense "the results will be different".
> >> Which results are you talking a bout?
> > The results of running jit-lock-functions.  those which really perform
> > fontifications result in faces, others result in whatever they do.
> 
> Yes, the code is different, so there are differences in the result of
> some internal steps.  But those "results" are internal.

They aren't internal, because faces are visible.

> Do you claim that it can result in a different rendering on screen?

That's one possibility, yes.  And for the functions that do something
other than fontifications, who knows what the results could be?

> 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?