Sorry I hit enter too early, I meant:
Kitty implemented in *2021* a slightly different *version* who apparently fixes some problems with fixterms.

Also see this comment about the «state of the art» of terminals:

https://github.com/mawww/kakoune/issues/2554#issuecomment-436300959

There are also at least three other protocols for "raw keyboard" input in terminals.

iTerm2 protocol
https://gitlab.com/gnachman/iterm2/-/issues/7440#note_129307021

Windows Terminal's "win32-input-mode"
https://github.com/microsoft/terminal/pull/6309

far2l terminal extensions
https://github.com/elfmz/far2l/blob/master/WinPort/FarTTY.h

The only one of them that already have some support in apps is far2l's one (apps supporting it are "turbo" text editor, "putty4far2l" putty fork, cyd01's "KiTTY"). It is tied to Windows keyboard codes, but translation from x11 codes is easy:
https://github.com/unxed/xkb2win/

I feel it's important to explain why the kitty keyboard protocol is truly essential.

I'm one of the developers of far2l—a port of the Far Manager file manager to Linux.  Since this program was originally developed for the Windows console, it heavily utilizes its advantages, particularly the ability to use any key combinations.

When migrating from Windows to Linux, users look for a familiar UX; they need their favorite applications, not a new operating system.  If we tell them "learn 100 new keyboard shortcuts," they're more likely to stay on Windows than listen to us.

Is it really acceptable that *nix console capabilities in the 21st century are still inferior to those of the ancient Windows 2000 console? This situation needs improvement.

In the far2l project, we came up with a hack that solves the problem under X11: we simply connect to X11 and listen to all keyboard input. This allows us to "refine" the key press information coming into the terminal, "deciphering" what the user actually pressed. A terrible, horribly dirty hack (but it works!)—but better than depriving the user of familiar functionality.

However, with the widespread transition to Wayland, this hack stops working.  What do you think users will do, give up their familiar keyboard shortcuts—or stay on X11?

This is precisely why we need the ability to use any keyboard shortcut in console applications. Not the day after tomorrow, not tomorrow. We needed it yesterday.

Of all the available solutions (far2l terminal extensions, iTerm2 raw keyboard protocol, win32-input-mode, and kitty keyboard protocol), the kitty protocol is the most suitable for UNIX-like operating systems. It's designed with backward compatibility in mind, and adapting terminals to support it is straightforward. Look at this code example. This is a reference implementation of basic kitty protocol support that I made as an example for Windows Terminal developers.  It's only 196 lines of code: https://gist.github.com/unxed/d979fe069039fe075c18eb0218b1f8f5

I hope you will consider these arguments, and together we can bring the console capabilities of UNIX-like operating systems up to par with what the Windows 2000 console offered 24 years ago. I'll be happy to answer any questions if anyone takes this on.  Thank you in advance!

This should also help with fish shell being able to use some keybinds, e.g. ctrl-backspace doesn't seem to really be possible right now, or at least is ambiguous with ctrl-h.

Ref https://github.com/fish-shell/fish-shell/issues/11538#issuecomment-3356580330

Here is some thoughts on fixterms/kitty approach vs another alternative, win32 input mode. I tend to believe that the win32 input mode is, in fact, much better designed.

Arguments in its favor:

1. It's based on a time-tested keyboard event structure of Windows - there have never been complaints from application developers that something is missing in it. The structure is stable and hasn't changed for decades.

2. It avoids the overcomplication of kitty's mode-state stack.

3. It doesn't include unnecessary and hard-to-obtain field unshifted key. (I understand how to implement this on top of GTK - it would require an additional xkbcommon context that tracks the current kb layout - but that's an absurd amount of terminal-side complexity for something that can be handled in a single line on the application side, simply by normalizing case before hotkey checks.)

4. It clearly separates Unicode character (which depends on layout and modifiers) and key code (which does not), unlike kitty, which allocates four (!) separate fields for the same two concepts: key code, shifted key code, base layout key code, and Unicode text.

5. Accordingly, there is no pointless duplication of the same Unicode character between the shifted field and the Unicode text fiels (as happens in kitty). Moreover, in kitty, for roughly half of all keys, the key code field itself duplicates the same character code as those two fields.

6. Parsing is simpler - no nested delimiters. Because of its simplicity, it's trivial to integrate into applications.

7. It's supported out of the box on every Windows machine.

8. The specification is clear and unambiguous.

9. It doesn't carry the 50-year-old technical debt that kitty indirectly inherits.

10. It's already used outside the Windows ecosystem - for example, in magiblot's Turbo Vision fork and his turbo editor, and also in far2l - Linux port of classical file manager from the Windows world.

On macOS, virtual key codes can be mapped the same way as in Wine, providing a familiar behavior at least for some users.

Essentially, with kitty we get a beautifully formatted specification that is, in at least one case, impossible to fully adhere to - one that contains fundamental design flaws and is excessively overengineered. To be honest, its appeal was greatly overestimated due to the lack of competition.

From an engineering standpoint, a protocol based on win32 input looks like a far more attractive alternative.

And it is already implemented for Konsole:
https://invent.kde.org/utilities/konsole/-/merge_requests/1133