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

[Stefan Monnier]

>> 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 ...


        Stefan