GNU bug report logs - #75886
31.0.50; read-multiple-choice / read-key and input-decode-map

Previous Next

To reply to this bug, email your comments to 75886 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; read-multiple-choice / read-key and input-decode-map
Date: Mon, 27 Jan 2025 07:07:46 +0100

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.

Bug 2:

I would have thought that replacing read-event with read-key in
reac-multiple-choice would have solved this, because read-key consults
input-decode-map. But that is not the case because read-key behaves
differently if input-decode-map has an entry for C-g or not.

Without input-decode-map for C-g.

#+begin_src emacs-lisp
  (read-key) ;; press C-g
  => Quit
#+end_src

With input-decode-map setting for C-g:

#+begin_src emacs-lisp
  (read-key) ;; press C-g
  => 7
#+end_src

Sorry for lumping these two bugs together, but I think it's easier to
understand this way.

Message #8 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 75886 <at> debbugs.gnu.org
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Mon, 27 Jan 2025 07:58:51 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> I would have thought that replacing read-event with read-key in
> reac-multiple-choice would have solved this, because read-key consults
> input-decode-map. But that is not the case because read-key behaves
> differently if input-decode-map has an entry for C-g or not.
>
> Without input-decode-map for C-g.
>
> #+begin_src emacs-lisp
>   (read-key) ;; press C-g
>   => Quit
> #+end_src
>
>
> With input-decode-map setting for C-g:
>
> #+begin_src emacs-lisp
>   (read-key) ;; press C-g
>   => 7
> #+end_src
>
> Sorry for lumping these two bugs together, but I think it's easier to
> understand this way.

I have to correct that, I confused read-event and read-key.

read-key never quits, it always returns ^G, input-decode-map or not

#+begin_src emacs-lisp
  (read-key) ;; press C-g
  => 7
#+end_src

read-event quits if not input-decode-map

#+begin_src emacs-lisp
  (read-event) ;; press C-g
  => Quit
#+end_src

Message #11 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 75886 <at> debbugs.gnu.org
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Mon, 27 Jan 2025 09:03:59 +0100

[Message part 1 (text/plain, inline)]

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> I would have thought that replacing read-event with read-key in
>> reac-multiple-choice would have solved this, because read-key consults
>> input-decode-map. But that is not the case because read-key behaves
>> differently if input-decode-map has an entry for C-g or not.
>>
>> Without input-decode-map for C-g.
>>
>> #+begin_src emacs-lisp
>>   (read-key) ;; press C-g
>>   => Quit
>> #+end_src
>>
>>
>> With input-decode-map setting for C-g:
>>
>> #+begin_src emacs-lisp
>>   (read-key) ;; press C-g
>>   => 7
>> #+end_src
>>
>> Sorry for lumping these two bugs together, but I think it's easier to
>> understand this way.
>
> I have to correct that, I confused read-event and read-key.
>
> read-key never quits, it always returns ^G, input-decode-map or not
>
> #+begin_src emacs-lisp
>   (read-key) ;; press C-g
>   => 7
> #+end_src
>
>
> read-event quits if not input-decode-map
>
> #+begin_src emacs-lisp
>   (read-event) ;; press C-g
>   => Quit
> #+end_src

The attached patch fixes things for me. It changes only
read-multiple-choice because read-key not quitting on C-g seems to have
been that way already in Emacs 30.

[0001-Use-read-key-in-read-multiple-choice-bug-75886.patch (text/x-patch, attachment)]

Message #14 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 75886 <at> debbugs.gnu.org
Subject: Re: bug#75886: 31.0.50;
 read-multiple-choice / read-key and input-decode-map
Date: Mon, 27 Jan 2025 14:37:40 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Mon, 27 Jan 2025 07:07:46 +0100
> 
> 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.
> 
> Bug 2:
> 
> I would have thought that replacing read-event with read-key in
> reac-multiple-choice would have solved this, because read-key consults
> input-decode-map. But that is not the case because read-key behaves
> differently if input-decode-map has an entry for C-g or not.
> 
> Without input-decode-map for C-g.
> 
> #+begin_src emacs-lisp
>   (read-key) ;; press C-g
>   => Quit
> #+end_src
> 
> With input-decode-map setting for C-g:
> 
> #+begin_src emacs-lisp
>   (read-key) ;; press C-g
>   => 7
> #+end_src
> 
> Sorry for lumping these two bugs together, but I think it's easier to
> understand this way.

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.

Thanks.

Message #17 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 75886 <at> debbugs.gnu.org
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
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

Message #20 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 75886 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Mon, 03 Feb 2025 06:03:49 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

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

Right, sorry. I corrected that else-mail.

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

In light of input-decode-map, it seems to me that using read-event is
always wrong. Should read-event be deprecated, maybe?

Should read-key be changed to signal quit? I find it a bit strange that
one can write Lisp that one cannot C-g out.

Message #23 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 75886 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Mon, 03 Feb 2025 06:13:14 -0500

>>> 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.
> In light of input-decode-map, it seems to me that using read-event is
> always wrong. Should read-event be deprecated, maybe?

I introduced `read-key` in the hope to replace `read-char` and
`read-event`.  But so far it's been hard to switch existing code (some
of those switches have been reverted, for example (and often without
understanding the root of the problem)).

> Should read-key be changed to signal quit?

I think this would break the use of `C-g` to exit from the minibuffer.


        Stefan

Message #26 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 75886 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Mon, 03 Feb 2025 20:13:38 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>> 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.
>> In light of input-decode-map, it seems to me that using read-event is
>> always wrong. Should read-event be deprecated, maybe?
>
> I introduced `read-key` in the hope to replace `read-char` and
> `read-event`.  But so far it's been hard to switch existing code (some
> of those switches have been reverted, for example (and often without
> understanding the root of the problem)).
>
>> Should read-key be changed to signal quit?
>
> I think this would break the use of `C-g` to exit from the minibuffer.

Too bad :-(.

Do you mind if I replace read-event with read-key in
read-multiple-choice? Maybe it sicks if I put a prominent comments why.

Message #29 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 75886 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Tue, 04 Feb 2025 08:40:19 -0500

>>> Should read-key be changed to signal quit?
>> I think this would break the use of `C-g` to exit from the minibuffer.
> Too bad :-(.

Of course, there's probably some way to fix the breakage, but basically,
it's a non-trivial change messing with a "delicate" issue (meaning one
where we currently have an undocumented balance of behaviors accumulated
over the years, and we're not even aware of it).

> Do you mind if I replace read-event with read-key in
> read-multiple-choice?

Not at all!

> Maybe it sticks if I put a prominent comments why.

I suggest you add a test for it as well (ideally in a separate commit so
`git revert` won't remove the test).


        Stefan

Message #32 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 75886 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Tue, 04 Feb 2025 15:42:04 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>>> Should read-key be changed to signal quit?
>>> I think this would break the use of `C-g` to exit from the minibuffer.
>> Too bad :-(.
>
> Of course, there's probably some way to fix the breakage, but basically,
> it's a non-trivial change messing with a "delicate" issue (meaning one
> where we currently have an undocumented balance of behaviors accumulated
> over the years, and we're not even aware of it).

Yeah :-/.

>
>> Do you mind if I replace read-event with read-key in
>> read-multiple-choice?
>
> Not at all!

Now done and closing in a minute.

>> Maybe it sticks if I put a prominent comments why.
>
> I suggest you add a test for it as well (ideally in a separate commit so
> `git revert` won't remove the test).

Slick idea, but I "trust" people to not want to drive me mad :-).

Message #39 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 75886 <at> debbugs.gnu.org
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Thu, 06 Feb 2025 05:30:10 +0100

Re-opened because map-y-or-n-p has the exact same problem.

Message #42 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 75886 <at> debbugs.gnu.org
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Fri, 13 Jun 2025 11:28:14 -0400

> diff --git a/lisp/emacs-lisp/rmc.el b/lisp/emacs-lisp/rmc.el
> index ad3c86cfd00..63f97fb006e 100644
> --- a/lisp/emacs-lisp/rmc.el
> +++ b/lisp/emacs-lisp/rmc.el
> @@ -219,8 +219,11 @@ read-multiple-choice--short-answers
>                                      (car elem)))
>                              prompt-choices)))
>                    (condition-case nil
> -                      (let ((cursor-in-echo-area t))
> -                        (read-event))
> +                      (let ((cursor-in-echo-area t)
> +                            (key (read-key)))
> +                        (when (eq key ?\C-g)
> +                          (signal 'quit nil))
> +                        key)
>                      (error nil))))
>            (if (memq (car-safe tchar) '(touchscreen-begin
>                                         touchscreen-end

LGTM,


        Stefan

Message #45 received at 75886 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 75886 <at> debbugs.gnu.org
Subject: Re: bug#75886: 31.0.50; read-multiple-choice / read-key and
 input-decode-map
Date: Sat, 14 Jun 2025 05:44:00 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> diff --git a/lisp/emacs-lisp/rmc.el b/lisp/emacs-lisp/rmc.el
>> index ad3c86cfd00..63f97fb006e 100644
>> --- a/lisp/emacs-lisp/rmc.el
>> +++ b/lisp/emacs-lisp/rmc.el
>> @@ -219,8 +219,11 @@ read-multiple-choice--short-answers
>>                                      (car elem)))
>>                              prompt-choices)))
>>                    (condition-case nil
>> -                      (let ((cursor-in-echo-area t))
>> -                        (read-event))
>> +                      (let ((cursor-in-echo-area t)
>> +                            (key (read-key)))
>> +                        (when (eq key ?\C-g)
>> +                          (signal 'quit nil))
>> +                        key)
>>                      (error nil))))
>>            (if (memq (car-safe tchar) '(touchscreen-begin
>>                                         touchscreen-end
>
> LGTM,
>
>
>         Stefan

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.