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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: casouri@gmail.com, 65451@debbugs.gnu.org
> Date: Fri, 25 Aug 2023 09:09:11 +0000
> 
> Eli Zaretskii <eliz@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.