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 11:24:37 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> I can see the danger running lisp code while buffer state is transient.
> 
> Would it be acceptable to accumulate treesit_record_change transactions
> into a queue, combine them later, and run the Elisp hook only when it is
> safe (around the same place `after-change-functions' is called, but only
> when actual edit is made to the buffer text)?
> 
> That way, we can have a hook that will run strictly less frequently
> compared to `after-change-functions'.

When exactly do you need this to run?  At the same time as
after-change-functions doesn't sound like a good idea to me, but I
think you don't need to run it there.  What about running just before
redisplay kicks in?

Or how about explaining how is the (updated) AST used, i.e. who are
the clients of the AST updates, and what do they do when the AST
changes?