all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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.