GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
Message #359 received at 78737 <at> debbugs.gnu.org (full text, mbox):
On June 14, 2025 3:50:41 AM EDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 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.
Sure: all things being equal, don't break working code.
>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.
The third option is that they handle the C-g they get like any other input. They don't have to necessarily treat it as a quit: for example, a terminal emulator might want to forward a C-g to a remote system.
Documenting new behavior should go without saying.
The requirement we document, IMHO should revolve around forward progress: whatever you do with the C-g shouldn't go back to reading a possible C-g in the same situation. Doing that would require the user to break out of your loop using multiple C-g, which is inconvenient.
(while (pcase (read-char) (1 (foo) t) (2 (bar) t) (_ (ding) nil)))
Fortunately, people tend not to write code like this.
This guidance applies to higher level input functions like read-key.
We should also mention in documentation that people should use these higher level functions unless they have a specific reason to use the lower level ones.
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.