[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: |
Sun, 27 Aug 2023 11:29:44 +0300 |
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: casouri@gmail.com, 65451@debbugs.gnu.org
> Date: Sun, 27 Aug 2023 08:13:38 +0000
>
> Eli Zaretskii <eliz@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.
- 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/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, 2023/08/26
- 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 <=
- 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