bug#67046: 29.1.50; map-y-or-n-p infinite loops if it's at the end of a kmacro

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  67046@debbugs.gnu.org
> Date: Tue, 14 Nov 2023 17:09:45 -0500
> 
> >> How can we be sure this doesn't introduce some regression?
> > I'm not certain, but the behavior as written is a completely inert
> > infinite loop, just sitting and spamming read-event over and over
> > forever and maxing out the CPU.  It seems hard for this to be correct
> > behavior.
> 
> Agreed.
> 
> >> Do you understand why this loop was added, in commit 3f72fac865?
> > I do not.
> 
> Neither do I.  The handling of keyboard macro wasn't very different from
> what we have now, so by my reading of the code it suffered from the same
> inf-loop as the one we're discussing.
> 
> I see that Gerd fixed that commit a week later by removing a `not` which
> strongly suggests the code wasn't tested very much, if at all.
> 
> > Maybe this was some kind of XEmacs confusion?  I don't know the full
> > history of keyboard macros, but perhaps in XEmacs read-event would start
> > returning keyboard input again after starting to return -1.  (In GNU
> > Emacs, AFAICT, it's always been the case that read-event returns -1
> > forever after we run out of input in the keyboard macro, but haven't yet
> > actually returned from the command loop)
> 
> Reading the code I'm wondering how come we don't get into inf-loops
> more often when executing macros that stop in the middle of a recursive
> edit, or minibuffer input, or ...

So what is the path forward?  Should we install the change on master
and cross our fingers?