Subject: bug#78916: 31.0.50; C-g fails to exit loop

From: Pip Cet <[email-masked]>
Date: Mon, 30 Jun 2025 18:15:40 +0000

"Stefan Monnier via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <[email-masked]> writes:

>>> > - Both keys behave like the "old C-g".
>>> > ?
>>> I'm fine with that.
>> Same, but does it mean 'C-g' will do the same as 'q'?  If not, what is
>> the difference between them?
>
> Hmm... so `q` is bound to `exit` which consumes the key and exits the
> Q&R loop.  In contrast `C-g` and `C-]` were bound to `quit` which is
> not handled exlicitly by the Q&R loop, instead it just pushes the event
> back on the `unread-commend-events` before exiting the loop, so in
> Mike's test case, `q` exits the inner Q&R and passes to the next,
> whereas `C-]` aborts all the subsequent Q&R calls after which it runs
> the global binding of `C-[`.

> I get the impression that the intention of the `replace.el` code when it
> pushes the event back on `unread-commend-events` is to make it run
> whichever binding is currently active "outside" (i.e. global or local
> keymap).
>
> IOW, we have many different ways to skin this cat and I'm not sure which
> is best.

I'd just like to speak out in favor of making read-key take an extra
argument to make it handle C-g the way read-event does; IIUC, the lack
of this argument is the real problem here.  If we don't, we should be
very careful about replacing read-event by read-key, and revert most
such changes.

Switching from read-event to read-key should be possible without the
(sometimes) undesirable change in C-g behavior.  That doesn't mean we
can't change the C-g/quit relationship at some future point; there's no
consensus to change behavior now (not even to make C-g and C-] the
same), so we shouldn't.

(I still think it would be easiest to give up on a single C-g signaling
a quit; if we move to requiring two C-g's, both of which are ordinary
input up to the point where the second one triggers a quit, all the
special cases go away.)

Pip