[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67046: 29.1.50; map-y-or-n-p infinite loops if it's at the end of a
From: |
Spencer Baugh |
Subject: |
bug#67046: 29.1.50; map-y-or-n-p infinite loops if it's at the end of a kmacro |
Date: |
Fri, 10 Nov 2023 17:35:23 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.