F13-F20 keybindings do not work

[hajdamak]

Platform e.g. macOS, Windows 11
Terminal software Ghostty, Windows Terminal

I am using Karabiner and AutoHotKey to generate F13-F20 key presses for some operations. This works fine in NeoVim however does not for Nushell keybindings. Keybindings for F1-F12 work fine though.

[fdncred]

It may be because crossterm doesn't support them on your os. Someone would have to look into it to confirm.

[hajdamak]

Yazi seems to be based on crossterm too but such bindinds work there fine.

[kronberger-droid]

@hajdamak
Two things would help narrow this down:

1. What bytes does the terminal actually send? (in bash with cat -v) and press F13-F20.
2. Do you have $env.config.use_kitty_protocol = true set? Crossterm parser seems buggy for these sequences.

[hajdamak]

@kronberger-droid

1. cat -v does not show anything for these when executed in Ghostty/Nushell. Same for keybindings listen. However cat -v in Terminal/zsh for example for F13 shows^[[25~
2. These bindings do not work regardless whether use_kitty_protocol is set to true or false.

[kronberger-droid]

Hmm okay, I will take a look.

[hajdamak]

Some additional findings. When Nushell is executed in Terminal then F13 binding works fine. Terminal uses only traditional escape sequences I believe.
Ghostty allows binding keys to explicit escape sequences, for example keybind = f13=text:\x1b[25~ will generate traditional escape sequence for F13. With this binding in Ghostty, F13 keybinding in Nushell works fine.
So it seems this is some kind of Ghostty <-> Nushell negotiation problem regarding Kitty/Traditional protocol usage.

[hajdamak]

@kronberger-droid Sorry, I have to retract my answer to your earlier question 2. After further testing F13 binding work fine in Ghostty/Nushell when use_kitty_protocol is set to true. So this solves my problem basically.
Nevertheless there is some kind negotiation problem to solve in order to make it work by default like in NeoVim or Yazi.

[kronberger-droid]

yeah yazi and neovim use kitty protocol by default if the terminal supports it. we could too. @fdncred. what do you think about it?

[fdncred]

I've fine with supporting kitty by default if the terminal support it

[catlover-bot]

I'd like to take a shot at this. Reedline already checks whether the terminal supports the Kitty keyboard protocol before enabling it, while Nushell currently defaults use_kitty_protocol to false. Based on the discussion here, I'll look at making the Nushell default opt in when supported while preserving the existing explicit opt-out.

[fdncred]

How would you tell if it's supported?

[catlover-bot]

I was referring to Reedline's existing kitty_protocol_available() check. It calls crossterm::terminal::supports_keyboard_enhancement().unwrap_or_default(), and KittyProtocolGuard::set(true) only enables the protocol when that probe reports support. So my thought was to make Nushell request the Kitty protocol by default, while still letting Reedline gate the actual activation on Crossterm's support check. I'll verify that behavior carefully before changing the default.

[fdncred]

i'm fine with that