[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65451: 30.0.50; `after-change-functions' are not triggered in the sa
From: |
Eli Zaretskii |
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@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.
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, (continued)
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/23
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Eli Zaretskii, 2023/08/23
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/24
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Eli Zaretskii, 2023/08/24
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/24
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Eli Zaretskii, 2023/08/24
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/24
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Eli Zaretskii, 2023/08/24
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Eli Zaretskii, 2023/08/25
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/25
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made,
Eli Zaretskii <=
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/27
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Eli Zaretskii, 2023/08/27
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/29
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/25
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Eli Zaretskii, 2023/08/25
- bug#65451: 30.0.50; `after-change-functions' are not triggered in the same order the changes are made, Ihor Radchenko, 2023/08/25