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: Sun, 27 Aug 2023 11:29:44 +0300

> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: casouri <at> gmail.com, 65451 <at> debbugs.gnu.org
> Date: Sun, 27 Aug 2023 08:13:38 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> 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.
> 
> What I meant is that similar principles with undo-limit-like variables
> may apply.

Well, the devil is in the details ;-)

> >> 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.
> 
> Fair point.
> Then, what about compacting the "edit list" more frequently, so that we
> do not need to worry about its size? But I am not sure what frequency
> will be safe.

Something like that, yes.  But we need to invent a protocol which
would allow several clients to consume the list safely and without the
risk of missing edits.

Previous Next

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