'ctrl+i' and 'ctrl+m' simulate 'Tab' and 'Enter' respectively

[GitFlzy]

Windows: 10.0.19045.6093 WSL 2.5.9.0 Debian 12 Nushell 0.105.1

'ctrl+i' and 'ctrl+m' simulate 'Tab' and 'Enter' respectively, like below:

~> keybindings listen
Type any key combination to see key details. Press ESC to abort.
code: Tab, modifier: KeyModifiers(0x0), flags: 0b000000, kind: Press, state: KeyEventState(0x0)
code: Enter, modifier: KeyModifiers(0x0), flags: 0b000000, kind: Press, state: KeyEventState(0x0)

I roughly understand the output after some search, but I think this is an unexpected and unwanted behavior, at least put them in default keybindings explicitly if people need them.

[Bahex]

This is not something that reedline decides to interpret identically for backwards compatibility or historical reasons. Unless specifically requested by the shell (or another program like vim), the terminal itself sends identical input for these keys.

Distinguishing these keys requires enabling kitty's keyboard protocol.

In nushell for example, this is toggled with $env.config.use_kitty_protocol.

From config nu --doc:

# use_kitty_protocol (bool):
# A keyboard enhancement protocol supported by the Kitty Terminal. Additional keybindings are
# available when using this protocol in a supported terminal. For example, without this protocol,
# Ctrl+I is interpreted as the Tab Key. With this protocol, Ctrl+I and Tab can be mapped separately.
$env.config.use_kitty_protocol = true

[GitFlzy]

Thanks for the explanation, and it looks like Windows Terminal doesn't support the kitty config:

I want to supplement something I forgot in the post: These composite keys worked well on windows's nushell, while were parsed as <Tab> and <Enter> on WSL. I also tried to configure .json file of the terminal according to here, it worked on WSL, but not in Windows where it sent the raw string: