GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
View this message in rfc822 format
On June 14, 2025 4:54:25 AM EDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Sat, 14 Jun 2025 07:55:54 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: monnier <at> iro.umontreal.ca, dancol <at> dancol.org, 78737 <at> debbugs.gnu.org
>>
>> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>>
>> >> /* Request quit when it's safe. */
>> >> int count = NILP (Vquit_flag) ? 1 : force_quit_count + 1;
>> >> force_quit_count = count;
>> >> if (count == 3)
>> >> Vinhibit_quit = Qnil;
>> >> Vquit_flag = Qt;
>> >
>> > That's not "emergency quit", that's part of "emergency exit". A
>> > different, though related, feature.
>>
>> Sorry, still being dense. This code is not reached on text terminals,
>> so it's not part of what trouble.texi calls the Emergency Escape
>> mechanism. I thought you were using "emergency exit" to refer to the
>> Emergency Escape feature
>
>I was.
>
>> but the above suggests that "emergency exit"
>> includes both the Emergency Escape and triple-C-g behavior on GUI
>> terminals.
>
>It doesn't. The triple-C-g thing is not documented at all.
>
>> Triple C-g on a GUI terminal clears inhibit-quit and quits, breaking out
>> of loops such as:
>>
>> (let ((inhibit-quit t))
>> (while t))
>
>Btw, the triple-C-g doesn't break this on Windows in a GUI session.
>handle_interrupt is not called at all on Windows when I press C-g.
>
>> This:
>>
>> 1. requires *three* C-g presses
>> 2. does not trigger an Emergency Escape or exit Emacs
>> 3. is unreachable on text terminals
>
>If we want to adverse this, we need to document it in the same place
>as the emergency exit.
>
>> Since this behavior does not exit Emacs, I thought it would not count as
>> part of the "emergency exit" feature.
>
>Indeed, it doesn't.
>
>> >> The "emergency" part is clearing the inhibit-quit flag when
>> >> force_quit_count reaches 3. The bug is that it should be >= 3, and the
>> >> questionable design feature is that we should reset the counter if
>> >> Vquit_flag and Vinhibit_quit are both nil, not just based on Vquit_flag.
>> >
>> > It isn't a bug, because emergency exit happens when the count is 2.
>>
>> No, nothing special happens when the count reaches 2.
>
>On TTY frames, it does, doesn't it?
>
>> These two are mutually exclusive:
>>
>> The code incrementing force_quit_count is unreachable on text terminals.
>>
>> The code implementing the Emergency Escape feature is unreachable on GUI
>> terminals.
>
>OK, so once we've established that, what's your point?
>
>> I note that this triple-C-g behavior is documented only in the code;
>> it's missing from trouble.texi.
>
>Yes, but the correct place to document it is in the same section where
>the emergency exit is described. And talking about inhibit-quit in
>the user manual is wrong, because users aren't expected to know about
>that. And finally, if we want to advertise this, we had better made
>it work on all supported platforms.
>
>Last, but not least, this is not directly related to the main part of
>this discussion, which is about being able to interrupt Lisp programs
>by a single C-g.
Why is it so important that a *single* C-g interrupt a Lisp program? If a Lisp program is reading input, and C-g is input, treating at least the first C-g as input is expected, and like I said, it's just not possible to interrupt with a single C-g a program expecting to read input that is also a single C-g. If you try to achieve this goal you either break the input capability or you break the single C-g quit, and you're not addressing this contradiction head on.
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.