Push Kitty keyboard enhancement flags to the host terminal #2
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
felis-tui reads host keys through crossterm but never pushes Kitty keyboard enhancement flags to the host terminal (no
PushKeyboardEnhancementFlagsanywhere insrc/). The host therefore emits legacy xterm bytes, and crossterm's legacy decoding collapses Ctrl+I / Tab, Ctrl+M / Enter, Ctrl+H / Backspace, Shift on letters, and Alt+x / ESC x beforekeys.rsever sees them. An application inside the felis session that has negotiated Kitty keyboard mode (the shadow'skitty_kbd_flags) then receives a lossy re-encoding, even when the host terminal is felis itself and supports the full protocol.This is the fidelity gap felis#299 attributed to the crossterm seam; it exists independently of which decoder runs, and closes without any felis core change.
Proposal
TermGuard::enter, querysupports_keyboard_enhancement()and, when true, pushDISAMBIGUATE_ESCAPE_CODES | REPORT_EVENT_TYPES | REPORT_ALTERNATE_KEYS | REPORT_ALL_KEYS_AS_ESCAPE_CODES; pop on drop, alongside the raw-mode and alternate-screen restore.keys.rs: stop treating every non-Release as a press once event types are reported (repeat stays a press; release now reacheskey_encode, which already suppresses it unless the session asked for releases).config.rsmust keep working with the enhanced key model (Shift now arrives as a modifier on the letter, not as an uppercaseChar).Not in scope
Replacing crossterm; see felis#299 for the rejected direction and its revisit conditions.
Refs
src/main.rsTermGuard,src/keys.rs,src/config.rsevent::KeyboardEnhancementFlags,PushKeyboardEnhancementFlags,supports_keyboard_enhancement