[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45834: 28.0.50; Mouse events in terminal emacs
From: |
Stefan Monnier |
Subject: |
bug#45834: 28.0.50; Mouse events in terminal emacs |
Date: |
Wed, 08 Sep 2021 22:22:48 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Eli wrote:
> I meant the original input: "ESC [ I" This should be a complete key
> sequence, given the following:
>
> (define-key map "\e[I" #'xterm-translate-focus-in)
`xterm-translate-focus-in` works at the level of keysequence remapping,
so "ESC [ I" is indeed a complete sequence but *for a remapping* and
it's remapped to the empty keysequence, which is not a complete keysequence.
In the sense of `C-h k`, "\e[I" is not bound to `xterm-translate-focus-in`.
AFAIK we don't currently have a command to query which key-remapping
happened for a given sequence of events, IOW, there is no equivalent to
`C-h k` that could tell the user that "\e[I" is "bound" to
`xterm-translate-focus-in`.
The closest that we have is that `C-h k` will tell the users both the
remapped keysequence and the original ("untranslated") keysequence.
> But for some reason, "C-h k" thinks it's an incomplete key sequence,
> because "C-h k" followed by a click on a different frame displays
> "ESC [ I-" (note the dash). Do you understand why this happens?
Yes because "ESC [ I" is not a sequence of events that is sufficient to
successfully find a command bound to it in the normal keymaps (global
map, local map, minor mode maps, ...). It's only bound in the
key-remapping maps, which are handled at another level (e.g. when the
users hit `C-h k mouse-1` in an xterm, they are told which command
`mouse-1` runs rather than which function was used to remap the byte
sequence into the `mouse-1` event).
Lars wrote:
> It's not so much wrong as just pretty confusing. That is, the original
> complaint is that saying `C-h k' and then focusing on some other app
> will leave Emacs saying "Describe the following ...: ESC [ O -", which
> wasn't the case in Emacs 26 (because we hadn't enabled mouse-in/out in
> xterm.el).
Indeed, the echoed keys are poor here. I don't know why we have that
here: when I bind `f6` to a prefix keymap and I hit `f6` in xterm, I see
`f6-` in the echo area rather than `M-[ 1 7~-`, so there's something odd
going on, but AFAICT the problem is "cosmetic" in the sense that it only
affects the echoed keys.
I thought the bug report here was about a problem beyond the set of keys
that were echoed.
Stefan
- bug#45834: 28.0.50; Mouse events in terminal emacs, (continued)
- bug#45834: 28.0.50; Mouse events in terminal emacs, Eli Zaretskii, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Lars Ingebrigtsen, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Eli Zaretskii, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Lars Ingebrigtsen, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Eli Zaretskii, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Lars Ingebrigtsen, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Eli Zaretskii, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Lars Ingebrigtsen, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Stefan Monnier, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs, Eli Zaretskii, 2021/09/08
- bug#45834: 28.0.50; Mouse events in terminal emacs,
Stefan Monnier <=
- bug#45834: 28.0.50; Mouse events in terminal emacs, Eli Zaretskii, 2021/09/09
- bug#45834: 28.0.50; Mouse events in terminal emacs, Stefan Monnier, 2021/09/09
- bug#45834: 28.0.50; Mouse events in terminal emacs, Lars Ingebrigtsen, 2021/09/09
- bug#45834: 28.0.50; Mouse events in terminal emacs, Stefan Monnier, 2021/09/09
- bug#45834: 28.0.50; Mouse events in terminal emacs, Lars Ingebrigtsen, 2021/09/08