GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
Message #353 received at 78737 <at> debbugs.gnu.org (full text, mbox):
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 55 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.