Some Alt keyboard shortcuts trigger escape key.

[amano-kenji]

1. Alacritty // TERM=alacritty. Alt+h and Alt+l are recognized properly by brick. Alt+PageDown, Alt+PageUp, Alt+Ins, and Alt+Del trigger escape key in brick. Pressing Alt+[ twice also triggers escape key.
2. st // TERM=st-256color. Alt+h and Alt+l are recognized properly by brick. Alt+PageDown, Alt+PageUp, Alt+Ins, and Alt+Del have the same keycodes as PageDown, PageUp, Ins, and Del. Pressing Alt+[ twice triggers escape key. Ins triggers escape key somehow.
3. foot // TERM=foot. The same result as alacritty.

Alt+PageUp, Alt+PageDown, Alt+Home, and Alt+End all work fine in weechat to scroll the current buffer in alacrity and foot. In st, Alt+PageUp, Alt+PageDown, Alt+Home, and Alt+End are the same as PageUp, PageDown, Home, and End.

https://weechat.org/files/doc/stable/weechat_user.en.html#key_bindings_buffers challenges vty to step up its terminal game.

To generate scrollable contents in weechat, type /help, /help server, or any help topic.

I also discovered a peculiar behavior around Backspace and Ctrl+h.

• If I press Ctrl+V and Ctrl+h, I get ^H in alacritty, st, and foot.
• If I press Ctrl+V and Backspace, I get ^? in alacritty, st, and foot.
• If I press Ctrl+V and Ctrl+Backspace, I get ^H in alacritty, st, and foot.

However, EvKey KBS [MCtrl] or EvKey (KChar 'h') [MCtrl] is not triggered when I press Ctrl+h or Backspace or Ctrl+Backspace. EvKey KBS [] is triggered when I press Ctrl+h, Backspace, Ctrl+Backspace, Shift+Backspace, or Backspace with other modifers.

[amano-kenji]

It seems this can be worked around with vty config, but fixing this properly will require a better keyboard protocol whether it is kitty keyboard protocol or something else. I will continue further discussion in an earlier issue on this repository.

[amano-kenji]

My attention came briefly here after the issue about terminal image protocol is closed.

I'd like to summarize the situation here.

I think it's safe to say that terminal input is broken at this point. There are keyboard protocols like kitty keyboard protocol, but terminal emulator authors don't agree that kitty keyboard protocol is good. For example, kitty keyboard protocol adds questionable things like Win key shortcuts.

If there is actually a good keyboard protocol in the future, I think issues like these can be closed by implementing the protocol.

I think the issue about terminal image protocol was closed because there is not yet a good standard for terminal images. I think the right approach for terminal image and terminal input is to wait for a good protocol to emerge.

[amano-kenji]

Am I right that you want a good standard rather than comparing various questionable ways of doing something which will be replaced by a standard later?

[jtdaugherty]

@amano-kenji I have a similar view about terminal input; I don't know if it's broken but I do find it confusing. I wish a good standard existed, and it seems like there are some out there and people are making an effort, but unfortunately they are only valuable if they are widely-supported. Until then they are no better than not having a standard since we still have to be compatible with all of the old less-than-ideal ways of dealing with input.

As for this ticket, though, I still want to get around to improving your situation. @kquick did some testing and found some results that might help, but I found them confusing and I haven't had time to take a closer look. I re-opened this because I think we can improve your situation by adding more sequence mappings to vty. I don't think that the best fix is to implement a new input protocol because I'm more concerned with finding a solution that improves input support across a wider variety of emulators.