input-decode-map: Silently ignore certain sequences

input-decode-map: Silently ignore certain sequences

[Yuri Khan]

Hello emacs-devel,

I am trying to implement an input-decode-map for the Kitty terminal
emulator [1], specifically, for its full keyboard mode extension [2].
This would solve one of the two major deficiences of Emacs in a
terminal emulator, namely, the inability to distinguish many
keystrokes. (The other one, lack of full color, is also solved by
Kitty, with the right terminfo modifications.)

In the full keyboard mode, the terminal passes to the application
*all* keystrokes, in a very machine-friendly format. That is, for
events other than character input (i.e. normal characters, shifted
characters, Enter, Tab, and Backspace), it sends an escape sequence
containing a key code, a modifier bit mask, and whether the key was
pressed, released, or autorepeated.

This is a bit too much for an application such as Emacs; in
particular, it is not interested in key release events, or events
regarding modifier keys.

To give an example, Kitty sends the sequence “ESC _ K p A B b ESC \”
for the event “Left Alt pressed”.

I can get Emacs to ignore this sequence by doing this:

    (define-key input-decode-map "\e_KpABb\e\\" [])

However, input decoding is accompanied by echoing the current key
sequence prefix, and when the sequence is complete, Emacs clears the
echo area. With key release events, this happens *a lot*. This is
suboptimal because sometimes Emacs asks a question in the echo area
and waits for a key.

For example, when the user presses C-x C-c, (kill-emacs) may ask
whether to save files. Then the release event for C-c comes, and the
echo area is cleared.

Is there a way to turn off echoing for prefixes of sequences matched
against input-decode-map, so that echoing still works for “manual” key
sequences but not sequences sent by the terminal?

If not, would such an option be considered useful?


[1]: https://sw.kovidgoyal.net/kitty/
[2]: https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling

Re: input-decode-map: Silently ignore certain sequences

[Stefan Monnier]

> Is there a way to turn off echoing for prefixes of sequences matched
> against input-decode-map, so that echoing still works for “manual” key
> sequences but not sequences sent by the terminal?

IIUC the problem you see is not that the sequence is echoed but that the
echo area is cleared at an inopportune moment.

> If not, would such an option be considered useful?

I don't see any reason off-hand to oppose such an option, but someone
will first have to figure out exactly which part of the code is
responsible for this clearing of the echo area.

Maybe it's just a plain bug because some part of the code didn't take
into account the possibility to rewrite a key sequence to the
empty sequence.


        Stefan

Re: input-decode-map: Silently ignore certain sequences

[Yuri Khan]

On Fri, Dec 14, 2018 at 5:44 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > Is there a way to turn off echoing for prefixes of sequences matched
> > against input-decode-map, so that echoing still works for “manual” key
> > sequences but not sequences sent by the terminal?
>
> IIUC the problem you see is not that the sequence is echoed but that the
> echo area is cleared at an inopportune moment.

Yes.

> I don't see any reason off-hand to oppose such an option, but someone
> will first have to figure out exactly which part of the code is
> responsible for this clearing of the echo area.

I did and filed a bug:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33749

Re: input-decode-map: Silently ignore certain sequences

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

Hi!

I found myself in a similar situation with an experimental package I've
been working on, mode-line-keyboard [1]. In this package I need to ignore
event, like key down, all together. My solution is to bind functions to
input-event-map that calls `read-key` recursively, as I found that
returning nil breaks a key sequence. I just realised that I haven't tried
[] so I might need to revisit this.

Anyway, I found the key map handing in Emacs really confusing. To help me
out I put together a companion package, keymap-logger [2], that logs most
things that is passed to and transformed by the various keymaps like
input-key-map and key-translation-map. Maybe it can help you to gain some
insight of what is going on.

    -- Anders

[1]: https://github.com/Lindydancer/mode-line-keyboard
[2]: https://github.com/Lindydancer/keymap-logger



On Thu, Dec 13, 2018 at 8:11 PM Yuri Khan <yurivkhan@gmail.com> wrote:

> Hello emacs-devel,
>
> I am trying to implement an input-decode-map for the Kitty terminal
> emulator [1], specifically, for its full keyboard mode extension [2].
> This would solve one of the two major deficiences of Emacs in a
> terminal emulator, namely, the inability to distinguish many
> keystrokes. (The other one, lack of full color, is also solved by
> Kitty, with the right terminfo modifications.)
>
> In the full keyboard mode, the terminal passes to the application
> *all* keystrokes, in a very machine-friendly format. That is, for
> events other than character input (i.e. normal characters, shifted
> characters, Enter, Tab, and Backspace), it sends an escape sequence
> containing a key code, a modifier bit mask, and whether the key was
> pressed, released, or autorepeated.
>
> This is a bit too much for an application such as Emacs; in
> particular, it is not interested in key release events, or events
> regarding modifier keys.
>
> To give an example, Kitty sends the sequence “ESC _ K p A B b ESC \”
> for the event “Left Alt pressed”.
>
> I can get Emacs to ignore this sequence by doing this:
>
>     (define-key input-decode-map "\e_KpABb\e\\" [])
>
> However, input decoding is accompanied by echoing the current key
> sequence prefix, and when the sequence is complete, Emacs clears the
> echo area. With key release events, this happens *a lot*. This is
> suboptimal because sometimes Emacs asks a question in the echo area
> and waits for a key.
>
> For example, when the user presses C-x C-c, (kill-emacs) may ask
> whether to save files. Then the release event for C-c comes, and the
> echo area is cleared.
>
> Is there a way to turn off echoing for prefixes of sequences matched
> against input-decode-map, so that echoing still works for “manual” key
> sequences but not sequences sent by the terminal?
>
> If not, would such an option be considered useful?
>
>
> [1]: https://sw.kovidgoyal.net/kitty/
> [2]:
> https://sw.kovidgoyal.net/kitty/protocol-extensions.html#keyboard-handling
>
>

[-- Attachment #2: Type: text/html, Size: 3894 bytes --]

Re: input-decode-map: Silently ignore certain sequences

[Yuri Khan]

On Sun, Dec 16, 2018 at 7:20 PM Anders Lindgren <andlind@gmail.com> wrote:

> I found myself in a similar situation with an experimental package I've been working on, mode-line-keyboard [1]. In this package I need to ignore event, like key down, all together. My solution is to bind functions to input-event-map that calls `read-key` recursively, as I found that returning nil breaks a key sequence. I just realised that I haven't tried [] so I might need to revisit this.

I did not consider calling ‘read-key’ from a function bound in
‘input-event-map’. Instinctively, I’d try to avoid side effects and
especially recursion in any of the key translation maps. Too
complicated for me :)

I had tried binding nil and #'ignore; neither worked. So I dived into
reading C code to get some superficial understanding how
‘input-event-map’ operates.

The short gist of it is that:

* A nil binding is treated, as usual in keymaps, equivalently to no
binding at all. That is, the sequence is not remapped.

* A function gets called with one argument (optional text of the
prompt) and its return value is used as if it was the binding (except
that if it’s again a function, it will not be called).

* A string is treated the same way as a vector of characters.

* The ultimate resolution of input-decode-map is a vector of keys,
which are stuffed in place of the original subsequence and the
resulting sequence is re-interpreted.


> Anyway, I found the key map handing in Emacs really confusing. To help me out I put together a companion package, keymap-logger [2], that logs most things that is passed to and transformed by the various keymaps like input-key-map and key-translation-map. Maybe it can help you to gain some insight of what is going on.

That is interesting, although not directly leading to a solution to my case.

I wanted to know when and why the echo area gets cleared, and I found
out that it happens when any prefix key is pressed and it’s pretty
much a feature. So my current idea of a solution is to save and
restore the echo area at appropriate times. I drafted a patch to that
effect:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33749#17

Re: input-decode-map: Silently ignore certain sequences

[Stefan Monnier]

> I did not consider calling ‘read-key’ from a function bound in
> ‘input-event-map’. Instinctively, I’d try to avoid side effects and
> especially recursion in any of the key translation maps.

Wise.

Also, using `read-key` and `read-event` is often a source of corner-case
problems, so it's better to stay away from them as much as possible.


        Stefan