* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
@ 2025-01-27 6:07 Gerd Möllmann
2025-01-27 6:58 ` Gerd Möllmann
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Gerd Möllmann @ 2025-01-27 6:07 UTC (permalink / raw)
To: 75886
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-01-27 6:07 bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map Gerd Möllmann
@ 2025-01-27 6:58 ` Gerd Möllmann
2025-01-27 8:03 ` Gerd Möllmann
2025-01-27 12:37 ` Eli Zaretskii
2025-02-06 4:30 ` Gerd Möllmann
2 siblings, 1 reply; 11+ messages in thread
From: Gerd Möllmann @ 2025-01-27 6:58 UTC (permalink / raw)
To: 75886
Gerd Möllmann <gerd.moellmann@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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-01-27 6:58 ` Gerd Möllmann
@ 2025-01-27 8:03 ` Gerd Möllmann
0 siblings, 0 replies; 11+ messages in thread
From: Gerd Möllmann @ 2025-01-27 8:03 UTC (permalink / raw)
To: 75886
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Gerd Möllmann <gerd.moellmann@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.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-read-key-in-read-multiple-choice-bug-75886.patch --]
[-- Type: text/x-patch, Size: 1296 bytes --]
From 0dbe8060b375e317a0e2709141cda7ff6ea03a76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org>
Date: Mon, 27 Jan 2025 08:58:30 +0100
Subject: [PATCH] Use read-key in read-multiple-choice (bug#75886)
* lisp/emacs-lisp/rmc.el (read-multiple-choice--short-answers):
Use read-key instead of read-event because read-event doesn't
use input-decode-map.
---
lisp/emacs-lisp/rmc.el | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
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
--
2.48.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-01-27 6:07 bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map Gerd Möllmann
2025-01-27 6:58 ` Gerd Möllmann
@ 2025-01-27 12:37 ` Eli Zaretskii
2025-02-02 23:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-06 4:30 ` Gerd Möllmann
2 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2025-01-27 12:37 UTC (permalink / raw)
To: Gerd Möllmann, Stefan Monnier; +Cc: 75886
> From: Gerd Möllmann <gerd.moellmann@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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-01-27 12:37 ` Eli Zaretskii
@ 2025-02-02 23:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 5:03 ` Gerd Möllmann
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-02 23:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gerd Möllmann, 75886
>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-02-02 23:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-03 5:03 ` Gerd Möllmann
2025-02-03 11:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 11+ messages in thread
From: Gerd Möllmann @ 2025-02-03 5:03 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 75886, Eli Zaretskii
Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-02-03 5:03 ` Gerd Möllmann
@ 2025-02-03 11:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 19:13 ` Gerd Möllmann
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-03 11:13 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 75886, Eli Zaretskii
>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-02-03 11:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-03 19:13 ` Gerd Möllmann
2025-02-04 13:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 11+ messages in thread
From: Gerd Möllmann @ 2025-02-03 19:13 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 75886, Eli Zaretskii
Stefan Monnier <monnier@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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-02-03 19:13 ` Gerd Möllmann
@ 2025-02-04 13:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 14:42 ` Gerd Möllmann
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-04 13:40 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: 75886, Eli Zaretskii
>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-02-04 13:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-04 14:42 ` Gerd Möllmann
0 siblings, 0 replies; 11+ messages in thread
From: Gerd Möllmann @ 2025-02-04 14:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 75886, Eli Zaretskii
Stefan Monnier <monnier@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 :-).
^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map
2025-01-27 6:07 bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map Gerd Möllmann
2025-01-27 6:58 ` Gerd Möllmann
2025-01-27 12:37 ` Eli Zaretskii
@ 2025-02-06 4:30 ` Gerd Möllmann
2 siblings, 0 replies; 11+ messages in thread
From: Gerd Möllmann @ 2025-02-06 4:30 UTC (permalink / raw)
To: 75886
Re-opened because map-y-or-n-p has the exact same problem.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-02-06 4:30 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-27 6:07 bug#75886: 31.0.50; read-multiple-choice / read-key and input-decode-map Gerd Möllmann
2025-01-27 6:58 ` Gerd Möllmann
2025-01-27 8:03 ` Gerd Möllmann
2025-01-27 12:37 ` Eli Zaretskii
2025-02-02 23:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 5:03 ` Gerd Möllmann
2025-02-03 11:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-03 19:13 ` Gerd Möllmann
2025-02-04 13:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 14:42 ` Gerd Möllmann
2025-02-06 4:30 ` Gerd Möllmann
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.