bug-gnu-emacs
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]