bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: casouri@gmail.com, 65451@debbugs.gnu.org
> Date: Thu, 24 Aug 2023 07:46:06 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If these measures still don't help you enough, perhaps the conclusion
> > is that it isn't feasible to implement text parsers in Lisp, at least
> > as long as you want all those micro-optimizations of knowing exactly
> > which parts of the buffer text were modified (as opposed to only know
> > how many characters at the beginning and at the end of the buffer
> > remain unchanged, and reparse the rest).  Maybe it must be done in C,
> > if we want Emacs to remain a relatively safe environment.
> 
> Do I understand correctly that `treesit_record_change' is called
> __less frequently__ compared to before-change-functions and
> after-change-functions?

No, treesit_record_change is called at a lower level than
buffer-change hooks are, and therefore in some cases the hooks will
not be called, but treesit_record_change will be.

The frequency might be lower, but only because treesit_record_change
is called once per change; there's no separate "before" and "after"
calls.  In any case, the correspondence is not 1:1, because they are
called on different levels.

> If yes, I do not see how exposing it to Elisp will make things any
> worse than already available
> `before-change-functions'/`after-change-functions'.

Exposing buffer text changes to Lisp is inherently dangerous, because
Lisp code can do anything and everything in these hooks, and many
packages already do.  The fact that we allow this via those two hooks
is unfortunate as it is, but adding more opportunities for Lisp to do
potentially dangerous stuff, and doing that on a lower level, where
the buffer object is sometimes in a state that is not 100% consistent,
is unwise, to say the least.  It will make Emacs much less stable.
No, thanks.