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

From: Daniel Colascione <[email-masked]>
Date: Fri, 13 Jun 2025 08:55:08 -0700

On June 13, 2025 8:50:10 AM PDT, Eli Zaretskii <[email-masked]> wrote:
>> Date: Fri, 13 Jun 2025 07:48:54 -0700
>> From: Daniel Colascione <[email-masked]>
>> CC: [email-masked], [email-masked], [email-masked]
>> 
>> On June 13, 2025 7:46:41 AM PDT, Eli Zaretskii <[email-masked]> wrote:
>> >> Date: Fri, 13 Jun 2025 04:49:21 -0700
>> >> From: Daniel Colascione <[email-masked]>
>> >> CC: [email-masked], [email-masked], [email-masked]
>> >> 
>> >> 
>> >> 
>> >> On June 13, 2025 4:36:42 AM PDT, Eli Zaretskii <[email-masked]> wrote:
>> >> >> From: Daniel Colascione <[email-masked]>
>> >> >> Cc: Pip Cet <[email-masked]>,  [email-masked],
>> >> >>   [email-masked]
>> >> >> Date: Fri, 13 Jun 2025 00:53:38 -0700
>> >> >> 
>> >> >> > If you are talking about a GUI session, then IME the 'emergency exit"
>> >> >> > procedure isn't reliably working in that case, and I'm not sure the
>> >> >> > implementation intends to support that.  I always knew that it's only
>> >> >> > reliably working on TTY frames.
>> >> >> >
>> >> >> > Or are you talking about the effect of the changes on the branch?
>> >> >> 
>> >> >> FWIW, the purpose of my N-times-in-T-milliseconds-within-one-command
>> >> >> formulation of emergency exit is to get the mechanism working reliably
>> >> >> in all cases.
>> >> >> 
>> >> >> I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I recall
>> >> >> PGTK being similar?) and not have Emacs quit.  If I mash C-g, it
>> >> >> sometimes does, and sometimes doesn't.
>> >> >> 
>> >> >> Right now, the logic is this:
>> >> >> 
>> >> >>     {
>> >> >>       /* 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;
>> >> >>     }
>> >> >> 
>> >> >> IOW, the first quit after clearing Vquit_flag resets the count to one.
>> >> >> Maybe that's why it isn't working reliably right now.  If we reformulate
>> >> >> this mechanism not in terms of count == 3 (which is fiddly for all sorts
>> >> >> of reasons, since Vquit_flag can get reset) but in terms of the UX
>> >> >> directly --- N recent quits in T time in a single command --- we make
>> >> >> the whole thing more reliable.
>> >> >> 
>> >> >> If you set T=infinity and N=3, you get the current force quit UX (modulo
>> >> >> my upgrade-before-disabling-inhibit-quit thing), just more reliably, and
>> >> >> you can break out of arbitrary Lisp code.
>> >> >
>> >> >I suggest to leave the emergency exit feature alone for now, and focus
>> >> >on the interruptibility of Lisp programs.
>> >> 
>> >> That *is* the interruptabiltity of Lisp programs.l
>> >
>> >No, not in my book.  A Lisp program should be interruptible without
>> >killing the Emacs session.  "Emergency exit", OTOH, kills the Emacs
>> >session.
>> 
>> Maybe we're talking past each other? I'm not proposing anything that automatically kills Emacs. I'm not sure what would have given you the impression we were talking about killing Emacs.
>
>I was talking about "emergency exit", and you responded to that,
>that's what gave me the impression.  Emergency exit, as its name
>implies, exist the Emacs session.

Ah, I was reading it as exiting the *current operation* and returning to the command loop --- a synonym for emergency quit. 
I