Kitty Keyboard input with flags set to 0 has unexpected encodings.

[tmccombs]

What Operating System(s) are you seeing this problem on?

Linux Wayland

Which Wayland compositor or X11 Window manager(s) are you using?

Sway

WezTerm version

20240203-110809-5046fc22

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

if the kitty keyboard encoding is enabled, then setting the flags value to 0 changes the encoding for some key presses, in particular certain key combinations, such as CTrl+space are inconsistent with both the default key encoding and Kitty's "legacy" encoding.

To Reproduce

Run stty raw -echo && printf '\x1b[>0u' && cat -e

Then press try some key combinations listed in https://sw.kovidgoyal.net/kitty/keyboard-protocol/#legacy-functional-keys. In particular, combinations involving modifiers such as Ctrl+space. Notice that they often use the kitty protocol for escape sequences despite the flags not having "disambiguate escape codes" enabled.

Configuration

config.enable_kitty_keyboard = true

Expected Behavior

I would expect one of the following to be the case:

1. Setting the "flags" of the kitty keyboard protol to 0 would reset the terminal to the default key encoding.
2. Setting flags to 0 would imitate the "legacy" encoding described in the Kitty documentation.
3. If the disambiguate flag is unset, then don't use escape codes for disambiguation, but respect other flags.

Logs

No response

Anything else?

I'm not entirely sure what the the right thing to do here is, and I'm not sure if this is even something that matters in the wild, since I would anticipate most applications that use the kitty protocol would push a flags that does include the disambiguate flag, then pop when they are done. But it is inconsistent with how kitty handles this case.