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

Previous Next

Full log

Message #17 received at 67046 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67046 <at> debbugs.gnu.org
Subject: Re: bug#67046: 29.1.50; map-y-or-n-p infinite loops if it's at the
 end of a kmacro
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 ...


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.