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

[Stefan Monnier]

>> > 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?
> To achieve their goals, of course.

[ I'll call "client functions" those functions passed to
  `jit-lock-register`, like `font-lock-fontify-region`,
  `goto-address-fontify-region`, `bug-reference-fontify`, ...  ]

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.

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.

> 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.  The change makes almost no difference in this respect (it
might change the frequency of some cases, but most of the behaviors that
are possible in the new setup were also possible in the old setup).

>> 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.  Why would
anyone care about them.  Who and how or when would notice them?
Do you claim that it can result in a different rendering on screen?
Or do you claim that it can result in the need to write client
functions differently?
If so, could you give some kind of scenario where that could happen?
If not, what else?


        Stefan