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
Reported by: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Fri, 10 Nov 2023 16:45:01 UTC
Severity: normal
Found in version 29.1.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 67046 <at> 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?
This bug report was last modified 1 year and 187 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.