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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: casouri <at> gmail.com, 65451 <at> debbugs.gnu.org
Subject: bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made
Date: Thu, 24 Aug 2023 11:08:16 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: casouri <at> gmail.com, 65451 <at> debbugs.gnu.org
> Date: Thu, 24 Aug 2023 07:46:06 +0000
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.