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: 65451@debbugs.gnu.org
> Date: Tue, 22 Aug 2023 12:42:18 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The order of after-change notifications thus do not correspond to the
> >> order of buffer changes. Org mode is relying upon the correct change
> >> order to update parser cache with buffer modifications.
> >
> > I think Org mode is relying on something it should not.
> 
> Then, I'd like to point back to the previous discussion where I asked to
> expose to Elisp information about buffer changes available to
> tree-sitter.
> https://yhetil.org/emacs-devel/83tu8jq2vl.fsf@gnu.org/

I don't want to do that, sorry.  Not without a good understanding of
what exactly do you need from that and in what way.  If we will expose
anything, it will have to be the minimum possible exposure, not the
maximum, so I would like to understand this very well before I agree
to any change in this direction.

> If there is no guarantee that buffer modifications are not signaled in
> order, on-the-fly updates of the parsed AST will become impossible for
> Org, even if using markers (as you suggested in the linked thread).
> 
> In fact, I am not sure if tree-sitter will behave correctly if it is
> signaled changes in incorrect order.

I will defer to Yuan, but tree-sitter doesn't use these hooks, we call
its functions directly from insdel.c where needed.  This makes sense
for a library to which we link and whose interface code we control,
but giving such access to Lisp (and Org on top of that) is out of the
question.  We don't even give such access to modules.