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