GNU bug report logs -
#78916
31.0.50; C-g fails to exit loop
Previous Next
Full log
Message #65 received at 78916 <at> debbugs.gnu.org (full text, mbox):
>> > 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
This bug report was last modified 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.