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

[Spencer Baugh <sbaugh@janestreet.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Fri, 10 Nov 2023 11:47:36 -0500
>> 
>> >From d7aa9644b308a936926b1074d0f6eac3e425b011 Mon Sep 17 00:00:00 2001
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Fri, 10 Nov 2023 11:27:10 -0500
>> Subject: [PATCH] Don't infinite loop in map-y-or-n-p if at the end of kmacro
>> 
>> Previously, if map-y-or-n-p got -1 from read-event (indicating no
>> input due to the end of a keyboard macro), it would just infinite
>> loop.
>> 
>> Now it behaves like other commands which use read-event/read-char/etc,
>> and just errors when we try to look up -1 in our keymap and find
>> nothing.
>> 
>> Also, just for the sake of users, print a slightly prettier message
>> when this happens.
>> 
>> * lisp/emacs-lisp/map-ynp.el (map-y-or-n-p): Don't loop if we reach
>> the end of a keyboard macro.  (Bug#67046)
>
> You have removed the loop, so now the "try again" part is no longer
> working.

Yep.

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

> Do you understand why this loop was added, in commit 3f72fac865?

I do not.

> If so, can you explain why it was needed?

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)

Or it was just a bug from the start.