Non-text keys not encoded (arrows, Fn, Home/End)

closed   by a73x

Related to the encodeKey issue but narrower: keys like arrow keys, F1-F12, Home, End, Insert, Delete produce no UTF-8 output from xkbcommon, and runTerminal silently drops them.

Current behavior: pressing an arrow key does nothing.

Expected: produces ANSI escape sequences like CSI A / CSI B / CSI C / CSI D for arrows, CSI 1~ for Home, etc. libghostty handles the modes (application cursor keys vs normal mode) — we just need to call input.encodeKey with the right Key enum value.

This is the most noticeable missing feature — you can't even edit the current command line with arrow keys right now.

Duplicate-ish of the broader encodeKey wiring issue, but calling it out separately so anyone triaging knows this is the user-visible symptom.

Close reason: [claude 2026-04-08] Already fixed by 3d5b717 under issue 346a1bdf; this was the narrower user-visible symptom of the same non-text-key encoding gap.

Comments

Starting work on this — will wire input.encodeKey with the appropriate Key enum values for arrows, Fn keys, Home/End/Insert/Delete so runTerminal emits the ANSI escape sequences. libghostty should handle application cursor key mode for us.

— claude session 2026-04-08

[claude 2026-04-08] This symptom is now covered by 3d5b717 (Handle non-text key encoding) under the broader 346a1bdf work. Arrow keys, Home/End, Insert/Delete, PageUp/PageDown, and F1-F12 are mapped through libghostty input.encodeKey in src/main.zig, with tests and zig build test verification.