GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
Message #326 received at 78737 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 13 Jun 2025 14:38:22 -0400
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: monnier <at> iro.umontreal.ca, pipcet <at> protonmail.com, 78737 <at> debbugs.gnu.org
>
> On June 13, 2025 1:47:43 PM EDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >My current understanding is that what you propose will cause some
> >(most) programs to be interruptible with a single C-g, while some (in
> >particular those which call read-event) will need two or more C-g to
> >be interrupted. Is that correct?
>
> Yes.
Good.
> However, it looks right now like the class of program that has to be quit with a repeated C-g is extremely small. I've seen only contrived examples so far. Most programs do something with the result of calling read-event, and when they see C-g, either break out of their dispatch loop or do a C-g appropriate thing.
>
> Things using low level input events like that, however, tend to be either old or specialized.
>
> The most common code paths (e.g. isearch, transient, map-y-or-n-p, etc.) with dispatch loops already use higher level tools like read-key, read-char-from-minibuffer, or transient keymaps and so get C-g handled as an input event anyway.
>
> Has anyone complained that (while t (read-key)) doesn't admit keyboard quitting?
>
> In practice, based on experience so far, there's no practical need to press C-g any more often than one does on mainline.
>
> >If this is correct, then we need to decide whether this inconsistency
> >(one C-g vs several) is tolerable.
>
> I think it's correct only in theory. Maybe I'm wrong and there's some undiscovered case that this breaks. It's to discover these cases that it would be nice to test the branch and merge it to mainline. We can always put it behind a feature flag.
I don't think we can dismiss use cases just because they are rare.
When we get a bug report about some regression, we try to fix the
regression regardless of how frequent the recipe is. We do sometimes
decide not to fix such bugs, and in those cases we might bring up
arguments about importance and frequency of the situation. But first
we try to fix the bug without considering that.
So if we are going to have a policy of disregarding such regressions
in these cases, we need to see a broad agreement to it.
> >Thanks, but that doesn't answer my question, which is specifically
> >about the effect of C-g on Lisp programs, whether they call read-event
> >or don't call it.
>
> Lisp programs that don't call read-event, read-char, or read-char-exclusive don't see a change in behavior except for how, once we implement the repeated C-g work, users will be able to break out of loops like (while t (read-key)) by pressing C-g multiple times.
>
> I have yet to see a real program that does something like this, much less one that depends on bricking quit functionality in the user's Emacs session.
>
> Lisp programs that do call these low level functions see a contract change, as I detailed in my previous messages.
I understand that Lisp programs which do call those low-level
functions will need to either accept that they cannot be interrupted
by a single C-g, or add some Lisp to quit when they receive a keyboard
input event that's equal to quit-char, is that right? If so, we will
need to clearly identify and document the low-level functions affected
by this.
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.