[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70077: An easier way to track buffer changes
From: |
Eli Zaretskii |
Subject: |
bug#70077: An easier way to track buffer changes |
Date: |
Sat, 30 Mar 2024 15:49:45 +0300 |
> Cc: casouri@gmail.com, yantar92@gmail.com, qhong@alum.mit.edu,
> frederic.bour@lakaban.net, joaotavora@gmail.com, mail@nicolasgoaziou.fr,
> acm@muc.de, stephen_leake@stephe-leake.org, alan.zimm@gmail.com,
> monnier@iro.umontreal.ca, phillip.lord@russet.org.uk
> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Sat, 30 Mar 2024 09:51:13 +0000
>
> Before we discuss the API, may you allow me to raise one critical
> concern: bug#65451.
>
> If my reading of the patch is correct, your code is relying upon the
> buffer changes arriving in the same order the changes are being made.
> However, it is not always the case, as demonstrated in the linked bug
> report.
That bug report is about after-change-functions. Since Stefan didn't
yet describe where will the changes be recorded, it doesn't
necessarily follow that your worries are justified. They could be, of
course, but we should decide that after we hear the details.
In any case, who and where said the changes will be fetched by
track-changes-fetch must be in the order they were made? why is the
order at all significant?
- bug#70077: An easier way to track buffer changes, (continued)
bug#70077: An easier way to track buffer changes, Stefan Monnier, 2024/03/29
bug#70077: An easier way to track buffer changes, phillip . lord, 2024/03/29
bug#70077: An easier way to track buffer changes, Ihor Radchenko, 2024/03/30
- bug#70077: An easier way to track buffer changes,
Eli Zaretskii <=
bug#70077: An easier way to track buffer changes, Stefan Monnier, 2024/03/30