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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78737 <at> debbugs.gnu.org, dancol <at> dancol.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Date: Fri, 13 Jun 2025 17:33:33 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:
> Whether we need an "emergency quit" (whatever that means) is a
> related, but separate question.  Currently, what we have is the
> "emergency exit", which doesn't quit, but kills the session (with or
> without a core dump), and IME it doesn't work reliably in GUI
> sessions.

I think the behavior of C-g C-g C-g is, as you describe, very different
in GUI-only sessions and in sessions with a terminal frame: if there is
a terminal frame, we offer to auto-save and kill the session (there is
an option to continue the session, but I don't know whether it works);
if there isn't, we set inhibit-quit to nil and quit-flag to t and hope
for the best.  (This description simplifies things somewhat;
handle_interrupt has the gory details).

We don't even tell the user that if we modified inhibit-quit, there is a
significant risk they just destroyed their session and that they have to
restart Emacs.  On the other hand, many places assume inhibit-quit
doesn't change under them and don't react to such changes, so a C-g C-g
C-g may do nothing; in this case, you usually don't get a second chance
because of the force_quit_count > 3 behavior.

> Again, this is IMO a separate feature and a separate discussion.  The
> discussion about what a single C-g does and how to interrupt Lisp
> programs using C-g is much more important and therefore much more
> complicated.

I think both discussions are important, but they depend on each other in
this way:

I think improving C-g C-g C-g, a lot, is necessary *before* we put more
blank bullets into C-g than there already are.  In fact, it may be
easier to think of it as replacing it by something somewhere between the
current C-g and the current C-g C-g C-g.

My suggestion is (Someone Else) coming up with a proposal for a good
"C-g C-g" (which might involve a different key sequence entirely),
implementing it, and then, only then, can we decide whether Daniel is
right and single C-g should become a normal input event in more
(Daniel's proposal) or all (my modification; this is not what Daniel
proposed) situations.  Or maybe we want to put the genie back in the
bottle and make C-g mean "quit" again, in almost all situations, such as
in transient mode.

If C-g C-g (or the same functionality by any other name) works and works
well, should we really let our muscle memory of using a single C-g for
quit stand in the way of more consistent behavior, freeing C-g for
ordinary use (it'd still mean something quit-like, a polite warning that
you're about to hit C-g a second time)?

We could even think of it as a way in which Emacs stabilized beyond the
need for a two-keystroke quit key.

But, right now, we can't reliably use C-g to quit Lisp programs; we
can't reliably use C-g C-g C-g either; we can't *safely* use C-g C-g C-g
either; and we can't use C-g as an ordinary input event with perfect
safety (but we have code which, essentially, assumes CPUs are so fast
now that we can get away with it in practice).

(That last one may be fixable, and it needs fixing for the MPS branch.)

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.