Ctrl+[, Ctrl+I and Ctrl+M don't work in zsh/bash/less with the default config

[kzmiura]

Now that KKP is widely supported, would you consider making legacy encoding the default instead of fixterms?

With the default config, Ctrl+[, Ctrl+I and Ctrl+M are sent as CSI 91;5u, CSI 105;5u and CSI 109;5u. As a result, they don't work in many applications that only understand legacy input, such as zsh, bash and less.

As far as I can tell, Ghostty is the only one of these terminals that sends CSI-u for these keys by default:

Terminal	Ctrl+[ / Ctrl+I / Ctrl+M by default	KKP support
Ghostty	CSI-u	Yes
kitty	Legacy	Yes
Alacritty	Legacy	Yes
WezTerm	Legacy	Yes (opt-in via enable_kitty_keyboard)

Applications that want to tell these keys apart from Esc/Tab/Enter can still request it through KKP.

---

English isn't my first language, so I used Claude Code to help with the wording and research.
Sorry in advance if anything comes across the wrong way.

[sknoyon324234234234]

Can't speak to whether the default will change, but until then you can get the legacy behaviour for just those three keys with keybinds. The text: action sends raw bytes (Zig-style escapes):

keybind = ctrl+bracket_left=text:\x1b
keybind = ctrl+i=text:\x09
keybind = ctrl+m=text:\x0d

That's ESC, TAB and CR, exactly what zsh/bash/less expect from Ctrl+[, Ctrl+I and Ctrl+M.

One trade-off to be aware of: a keybind takes priority over the encoder, so apps that do turn on the Kitty keyboard protocol (Neovim, Helix, etc.) will also get the legacy byte and can't tell Ctrl+I from Tab anymore. If that matters to you, you could scope the bindings or only add the ones you actually miss. Ctrl+[ → ESC is usually the important one.

[kzmiura]

Thanks for taking the time to write up the workaround! It works well for the three keys I mentioned.

However, the problem isn't limited to these three key combinations. For example, Shift+Enter is sent as CSI 27;2;13~ by default, and bash and zsh insert garbage like ;2;13~ instead of treating it as Enter. Covering every case with keybinds would take a lot of configuration, so it seems hard to rely on as a general solution.

The trade-off you mentioned is actually one of the reasons I think there should be an option to disable fixterms, or a change to the default behavior. With keybinds, users have to choose between legacy apps working correctly and KKP-aware apps being able to tell Ctrl+I from Tab. If the extended encodings were only sent when an application requests them through KKP, both would work without any configuration.

[sknoyon324234234234]

Fair point, Shift+Enter and friends make per-key keybinds a losing game. Agreed that a config option to turn the extra key encoding off (or a different default) is the real fix, so the workaround is just a stopgap for those three keys.