Subject: bug#70077: An easier way to track buffer changes

From: Eli Zaretskii <[email-masked]>
Date: Sat, 30 Mar 2024 15:49:45 +0300

> Cc: [email-masked], [email-masked], [email-masked],
>  [email-masked], [email-masked], [email-masked],
>  [email-masked], [email-masked], [email-masked],
>  [email-masked], [email-masked]
> From: Ihor Radchenko <[email-masked]>
> 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?