GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
View this message in rfc822 format
> Date: Thu, 12 Jun 2025 18:37:58 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: dancol <at> dancol.org, monnier <at> iro.umontreal.ca, 78737 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz <at> gnu.org> 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?
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.