emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Monnier
Subject: Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%
Date: Sat, 04 Sep 2021 11:55:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]