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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 13 Jun 2025 08:52:40 +0300

> Date: Thu, 12 Jun 2025 18:37:58 +0000
> From: Pip Cet <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> 
> "Eli Zaretskii" <[email-masked]> writes:
> 
> > Please describe the situations where you'd like it to throw to top
> > level and it doesn't now.
> 
> One situation for ordinary quits; three for force-quit.
> 
> Situation 1:
> 
> I'd like read-event, when called while inhibit-quit is t, to report
> quits by setting quit-flag in addition to returning quit_char: it'll
> simplify the C code, and it would make
> 
> (while t
>   (let ((inhibit-quit t))
>     (read-event)))
> 
> quittable, as I naively expected it to be.  The old behavior would
> remain available, but require an extra let binding.

But isn't it confusing that to have something quittable one needs to
bind inhibit-quit non-nil?  The naïve expectation from this is that
the code affected by inhibit-quit non-nil is _not_ quittable, no?

> Note that this isn't
> (let ((inhibit-quit t))
>   (while t
>     (read-event)))

Which is also confusing by its inconsistency.  In general, the order
of let-bindings doesn't matter.

> Situation 3:
> 
> Several force-quits in the same session.  Reset force_quit_count to 0
> once it reaches 3.  I've seen force_quit_count reach higher values than
> 3 (there was no regular quit in between force quit attempts).

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?