Subject: bug#78737: sit-for behavior changes when byte-compiled

From: Daniel Colascione <[email-masked]>
Date: Sat, 14 Jun 2025 06:24:40 -0400

On June 14, 2025 4:54:25 AM EDT, Eli Zaretskii <[email-masked]> wrote:
>> Date: Sat, 14 Jun 2025 07:55:54 +0000
>> From: Pip Cet <[email-masked]>
>> Cc: [email-masked], [email-masked], [email-masked]
>> 
>> "Eli Zaretskii" <[email-masked]> 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.