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:

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

Elisp code that does not care about text property changes will not be
forced to use `before/after-change-functions' (because no other option)
and could be called less frequently.

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