Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map

From: Stefan Monnier <[email-masked]>
Date: Sun, 02 Feb 2025 18:25:50 -0500

>> 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