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

From: Stefan Monnier <[email-masked]>
Date: Wed, 02 Jul 2025 10:14:39 -0400

>> > and it happened in the past because C-g would quite right away, so
>> > there was no need to re-read it.  Right?
>> 
>> I agree that we want to signal `quit` right away here (and I think both
>> for `C-g` and for `C-]`) rather than "unread" them.  The question is how
>> we want to do it:
>> 
>> - (signal 'quit nil)
>> - call `keyboard-quit`.
>> - call whatever is bound to `C-g` in the normal keymaps.
>
> If you explain the difference between the first tow, I could try
> making up my mind.

I know as much as you do in this respect (i.e. the difference is
whatever `keyboard-quit` does before calling `(signal 'quit nil)`).

Also:

- (signal 'quit nil) is what C-g does/did when we use(d) `read-event`.
- `keyboard-quit` is what `C-g` does when it's handled via the global-map.

To me, the current situation sounds like a case where the `C-g` is
received by an "interactive loop" so I'd leaning towards handling it via
`keyboard-quit`, whereas (signal 'quit nil) is what is used when
interrupting *running* code.

>> [ With a subsidiary question of whether we do it by changing the code
>>   that handles a key bound to `quit` or whether we just change the
>>   binding to something else like `keyboard-quit`.  ]
>
> Currently 'quit' in replace.el is not handled, so it is a kind-of
> dummy binding.  It doesn't have any code that handles it.  Or what did
> I miss?

Yes, "any" other symbol would be handled in the same way, i.e. it's
handled by the default code that unreads the event and exits the Q&R.

        Stefan