M-PageDown and M-PageUp don't work in foot, alacritty, kitty

[subnut]

Terminals tested:

• foot (https://codeberg.org/dnkl/foot)
• alacritty (https://github.com/alacritty/alacritty)
• kitty (https://github.com/kovidgoyal/kitty)

Escape code produced

• Meta+Page Up

  ^[[5;3~
  

• Meta+Page Down

  ^[[6;3~
  

Possible causes

https://sw.kovidgoyal.net/kitty/keyboard-protocol

---

Continuation of glguy/irc-core#97

[jtdaugherty]

Thanks for reporting this. Looking over the glirc conversation, it's not clear to me what you are requesting. If you are wanting Vty to recognize the above escapes as Meta+PageUp/Down, I'm not sure that's even possible given that those escapes likely already get recognized as something else. As you have probably discovered, different terminal emulators behave differently when it comes to keyboard input, which is why Vty has the key event decoding configuration directives you were discussing in the other ticket. In general, Vty cannot support all possible sequences due to overlap/collisions.

[subnut]

it's not clear to me what you are requesting

I am requesting that \ESC[5;3~ be recognized as Meta+PageUp and \ESC[6;3~ be recognized as Meta+PageDown for the $TERM values foot and alacritty

given that those escapes likely already get recognized as something else

for foot and alacritty terminals, vty currently recognizes -

• \ESC[5;3~ as Esc [ 5 ; 3 ~
• \ESC[6;3~ as Esc [ 6 ; 3 ~

Vty has the key event decoding configuration directives you were discussing in the other ticket

Are you referring to the ~/.vty/config file?

[jtdaugherty]

I am requesting that \ESC[5;3~ be recognized as Meta+PageUp and \ESC[6;3~ be recognized as Meta+PageDown for the $TERM values foot and alacritty

RIght now Vty does not specifically have support for those particular terminals, and falls back to the terminfo driver for terminals whose TERM doesn't look like an xterm or screen. However, it's possible to do what you want in your application source by modifying the InputMap of the Config yourself by populating it with the custom input-to-event mappings rather than modifying the configuration file. That way, your application has control over additional mappings that it can install in the presence of some values of TERM.

Are you referring to the ~/.vty/config file?

I was, yes, but it might be cleaner to modify the Config data structure programmatically instead.