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: Ihor Radchenko <yantar92 <at> posteo.net>
To: Eli Zaretskii <eliz <at> gnu.org>
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:24:37 +0000

Eli Zaretskii <eliz <at> 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>

Previous Next

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