GNU bug report logs -
#75886
31.0.50; read-multiple-choice / read-key and input-decode-map
Previous Next
Full log
Message #17 received at 75886 <at> debbugs.gnu.org (full text, mbox):
>> I am running emacs -nw on a terminal supporting the Kitty Keyboard
>> Protocol, and I am using the kkp package from MELPA to make use of the
>> additional keys KKP makes possible to use.
>>
>> Must know:
>>
>> 1. Kkp works by adding entries to input-decode-map, among them a binding
>> for C-g, which arrives from the terminal as an escape sequence which
>> input-decode-map maps to ^G.
>>
>> 2. read-event does not consult input-decode-map:
>>
>> #+begin_src eemacs-lisp
>> (read-event) ;; press C-g
>> => 27
>> [103;5u
>> #+end_src
>>
>> 3. read-multiple-choice uses read-event.
>>
>> Bug 1:
>>
>> Modify a buffer and C-x k it. A prompt appears asking what to do. The
>> prompt comes from read-multiple-choice. Press C-g. That results in
>> "invalid choice" because read-multiple-choice gets (part of) the escape
>> sequence the terminal sends from read-event.
`read_char` usually doesn't return `C-g` but signals `quit` instead.
IOW the handling that makes `C-g` abort `C-x k` and friends is done at
a very low-level. IIRC whether it (should) return(s) `C-g` or signal(s)
quit depends on `immediate_quit` which is not reflected in ELisp.
>> Without input-decode-map for C-g.
>>
>> #+begin_src emacs-lisp
>> (read-key) ;; press C-g
>> => Quit
>> #+end_src
That's not what I see here. I get 7 (aka `C-g`) in an `emacs -Q`.
> This is a dark corner in Emacs, so I'm adding Stefan to the discussion
> in the hope that he might have comments and ideas to suggest.
Indeed `C-g` is handled (read: hard coded) at a very low-level.
Stefan
This bug report was last modified 60 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.