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

[Ihor Radchenko <yantar92@posteo.net>]

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

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>