Subject: bug#60467: 30.0.50; primitive-undo: Changes to be undone by function different from announced

From: Eli Zaretskii <[email-masked]>
Date: Mon, 26 Jun 2023 18:30:33 +0300

> Date: Mon, 26 Jun 2023 15:18:45 +0000
> From: Gregory Heytings <[email-masked]>
> cc: [email-masked], 
>     Frédéric Giquel <[email-masked]>, 
>     Eli Zaretskii <[email-masked]>, Ihor Radchenko <[email-masked]>, 
>     Alan Mackenzie <[email-masked]>
> 
> >> FYI, that issue is fixed with the 
> >> Fix-combine-change-call-with-timestamps patch.
> >
> > Oh, but I don't think this is OK for the `emacs-29` branch, so we still 
> > need a more targetted fix for the `emacs-29` branch.
> 
> Well, that bug was already discussed at length six months ago, and the 
> minimal change that was in the end installed (59c3c53efa) introduced a new 
> bug.  Should we design another minimal change, at the risk of introducing 
> another bug?  ISTM that the safe thing to do is the refactoring that was 
> suggested.

If there's no safer way than the refactoring suggested back then, we
will have to stay with this regression in Emacs 29.1 and install a
better fix only on master.  After all, the fact that buffer-modified-p
is not undone is a minor inconvenience at best.

I'm sorry, but I cannot wait too much time longer before the release.
The Emacs 29.1 release cycle already took significantly longer than I
ever imagined.  So if someone can think about some clever ideas to fix
what we have on the release branch by small and safe changes, please
speak up soon.