GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
View this message in rfc822 format
On June 13, 2025 1:47:43 PM EDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 13 Jun 2025 09:14:20 -0700
>> From: Daniel Colascione <dancol <at> dancol.org>
>> CC: pipcet <at> protonmail.com, 78737 <at> debbugs.gnu.org
>>
>> On June 13, 2025 9:03:21 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> >> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> >> Cc: Daniel Colascione <dancol <at> dancol.org>, 78737 <at> debbugs.gnu.org, Eli
>> >> Zaretskii <eliz <at> gnu.org>
>> >> Date: Fri, 13 Jun 2025 10:51:37 -0400
>> >>
>> >> > Making
>> >> >
>> >> > (while t (read-event))
>> >> >
>> >> > infloop without being able to quit is a bad idea. We shouldn't do it.
>> >>
>> >> I don't find this terribly problematic, If you think of what that loop
>> >> means it *is* a "please shoot me in the foot" kind of thing.
>> >>
>> >> I agree that not being able to escape is a problem, but it's not the
>> >> only way to get into such trouble. IOW I think it just gets us back to
>> >> the fact that we need an "emergency quit" for bugs (which `kill -USR2`
>> >> can sometimes provide, tho it's not a quit per-se).
>> >
>> >What I asked, and still didn't get an answer to, is at what point does
>>
>> I believe I answered your question at length in <https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-06/msg00678.html> and specifically addressed the question above. I believe I'd addressed the subject several times before as well.
>>
>> Could you please take a look at the proposal before declaring these questions unanswered?
>
>I did.
>
>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.
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.
>> >Later responses by Daniel seem to indicate that the answer is "never".
>> >It seems like his proposal is to change the behavior of C-g such that
>> >to interrupt a Lisp program the user will need two or more C-g presses
>> >(with the number customizable) during some predefine time interval.
>> >Is that understanding correct?
>>
>> No, that is not correct, and I've said so many times. I'm not sure what I could say to increase clarity.
>
>Is the modified description above correct? If not, what is incorrect
>in it?
>
>> Outside contrived corner cases, the only difference users will notice is that quitting works more reliably.
>
>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.
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.