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: Sat, 26 Aug 2023 10:10:02 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: casouri <at> gmail.com, 65451 <at> debbugs.gnu.org
> Date: Fri, 25 Aug 2023 09:09:11 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thinking about this some more, we will need to consider whether this
> > list of accumulated transactions is ever compacted by deleting old
> > transactions, or we let it grow indefinitely.  If the former, we
> > should consider the case where more than one feature wants to track
> > buffer edits (so it is impossible to remove entries once they have
> > been processed by a single consumer).
> 
> What I propose is actually quite similar to `buffer-undo-list'.
> But a bit less generic - (apply FUN-NAME ARGS) entries cannot be handled
> outside the narrow scope of `undo'.
> Similar to `buffer-undo-list' it needs to be compacted.

Not sure what this means in practice.  the entries in the list we are
discussing will be very different from the entries in
buffer-undo-list.

> To not lose the information when the edit history is compacted, there
> may be a hook executed right before the compaction, so that all the
> users can update their state as needed.

If the compaction will run from GC, then we cannot safely call Lisp
hooks at that time.

Previous Next

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