A potential flaw with the CSI kitty protocol and my workaround + a request for support of the AppCursor mode.

[oderwat]

TLDR: I think there is a bug with "Alt" keys and I hope that supporting "AppCursor" mode would let us make pretty cool key mappings for non US/GB layouts.

This will be a bit longer, bare with me please:

I am currently working on a new terminal / shell / layout / session / editor combination on my Mac (and Linux and WSL2) with a German keyboard. The keyboard layout is a "no dead keys" layout. But this is not mandatory. Important is, that it is not the US/GB keymap which means: ";,:,[]{}|" being in all the wrong places for tools like Vi and Helix. But we have "öäü" :)

Coming from iTerm2 + tmux + vi on servers, my new stack is now like this:

Alacritty -> NuShell -> Zellij -> Helix

My goal is to use Zellij instead of the Terminal tabs/panes locally and instead of tmux remotely. I also want to have as few clashing keys as possible.

For this I changed Zellij to use "Super" and "Alt + Super" ("Super" is "Command", "Alt" is Option). This works as long as Alacritty has the kitty extended key protocol enabled. But "Command + t" is normally "New Alacritty Tab", so I added bindings that remove those defaults which lets them go through to Zellij ({ key = "t", mods = "Command", action = "ReceiveChar" }).

This works pretty good. The extra key (Command) lets me quickly use the Zellij functions and keeps all other keys useable.

There are two problems though. I am totally new to all of this terminal stuff, so I hope I do make sense and use the right terms.

First for the (potential) bug:

For getting the "Options" key as "Alt" key in the terminal, I have to enable: option_as_alt = "OnlyLeft" in "Alacritty". If I don't do this, the "Left Options" key is also used for "compositions" and even with my "no dead keys" layout it will just send all those "special" characters. Like ç for "Options/Alt + c" and "nothing really" for "Options/Alt + C".

With "option_as_alt" the terminal receives "^[C" for "Option + Shift + c". But when "Zellij" is running and the Kitty protocol is not disabled, this changes to CSI 99 ; 4 u inside "Zellij" (shown by kitten show-key -m kitty). I think that "Helix" does support the kitty protocol too, but the CSI code is not working. When I disable the Kitty protocol support, Helix gets the "^[C" (ESC+C) and is happy though. But then, "Zellij" will not get the "Super + keys" anymore and that sucks.

I wonder if there is possibly a flaw in "Helix", which has the "Alt+C" mapping only react to the ESC+C encoding and not for the CSI variant of those keys? I also wonder that "Zellij" may have the "bug" that it forces the ESC+C variant into the CSI Kitty protocol, but that may be a feature, actually. Maybe this is all just a compatibility issue and not really something that can be called a bug.

If "Helix" actually has such a flaw and could be enhanced by checking for both: "^[C" and "CSI 99 ; 4 u" (aka 0x1bC and 0x1b 0x5b 0x39 0x39 0x3b 0x34 0x75), that may solve some remaining "My Alt keys mappings do not work in Helix" problems.

For myself I found a workaround by adding a key mapping for "Option + C" ({ key = "c", mods = "Shift | Option", chars = "\u001bC" }) to "Alacritty" which is then sent instead of the CSI code and voilà: I can use Alt + C in the editor. I do need to add this for all the other Alt variations too and would love if that is not needed.

Second for the "AppCursor" enhancement:

"Alacritty" lets me define key mappings that have a "mode" with them. From what I read, an application can set this mode (like "Alt", "AppCursor" and "AppKeypad") to indicate if features like scroll back make sense in that state.

Now back to my German keyboard. I think that if "Helix" would indicate "Normal Mode" as "AppCursor" I could map the "ö" key, which is at the place where US have ";" to ";" in that mode but to "ö" in all other modes. This way I could use the easier to reach key and even add "Alt" to it. Considered that using the German layout I have to press "Shift + ." for ";" and "Alt + Shift + ." for "Alt + ;" this would make using those keys much easier without losing the "ö" in edit mode.

As I wrote before. I just started today to "discover" about those terminal implementation stuff and hope my understanding is good enough to not have wasted your time by writing total nonsense. Thanks for reading!