GNU bug report logs - #78737
sit-for behavior changes when byte-compiled

Previous Next

Package: emacs;

Reported by: Daniel Colascione <dancol <at> dancol.org>

Date: Mon, 9 Jun 2025 20:50:02 UTC

Severity: normal

Full log


Message #143 received at 78737 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 78737 <at> debbugs.gnu.org, dancol <at> dancol.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Date: Fri, 13 Jun 2025 08:52:40 +0300
> 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.