[idea] keys.extended_keys: opt into Kitty report-all-keys so modifier+printable chords can be bound

[danielnadar75]

I'll be upfront about my bias here: this is the single thing that has kept me from moving off tmux properly.

My tmux prefix is a modifier+printable chord, and it just doesn't survive the trip into Herdr. Terminals send those as the bare character by default, so shift+space arrives byte-identical to Space and Herdr has no way to tell them apart. Same story for ctrl+shift+p and friends. Setting it as the prefix doesn't error, it just quietly does nothing, which took me a while to work out. Retraining my hands onto a different prefix after years of muscle memory was the one thing I kept bouncing off, so I never fully made the switch.

tmux handles this with set -s extended-keys on. As far as I can tell Herdr has no equivalent.

What I'd like

A [keys] opt-in that asks the host terminal for the Kitty keyboard protocol's REPORT_ALL_KEYS_AS_ESCAPE_CODES mode:

[keys]
extended_keys = true
prefix = "shift+space"

Off by default.

Why opt-in and not just always on

Report-all gets pushed without REPORT_ASSOCIATED_TEXT, so turning it on unconditionally interferes with CJK IME composition. Two things keep that contained:

• it stays off unless you ask for it
• even when it's on, it's withheld inside Herdr's own free-text modes (rename, goto, search), so those fields keep normal text input

The part I wasn't sure about

The host terminal that has to report the extra keys belongs to the client, but report-all mode is driven by the server. If the setting only lived in server config, a client attaching with HERDR_REMOTE_KEYBINDINGS=local would push report-all at setup and then have the server stream it straight back off again.

What seemed to fit the existing design was letting the opt-in travel with the keybinding profile it belongs to, next to prefix and the bindings, so whichever profile is in force also decides this. That needs no wire protocol change, since a local profile already ships in the handshake. Very open to being told that's the wrong call.

Where I'm at with it

I've had this running locally for the past couple of weeks and it has genuinely fixed the problem for me. I've been rebuilding it on top of each release to stay in sync with the latest, which works fine but isn't something I want to keep doing indefinitely.

Branch against current master, with docs, unit tests, and cargo fmt / clippy / the test suite / the Windows-target lint all clean:

https://github.com/danielnadar75/herdr/tree/keys-extended-keys

I'm posting here instead of opening a PR because that's what CONTRIBUTING.md asks for, but I can open one straight away if you'd like it. Equally happy to change the approach, or to leave this purely as a description of the problem if you'd rather implement it yourselves — I mostly just want it to exist.

Related

• [idea] Downgrade modified Enter to plain CR for panes that have not enabled an extended keyboard protocol (ssh remotes currently receive ^[[27;5;13~) #1591 is adjacent but different: that one is about what Herdr sends into panes, this is about what the host terminal reports to Herdr.