fix(tui): readline parity on Linux — Ctrl+A = home, Alt+B/F word nav#13594
Conversation
There was a problem hiding this comment.
Pull request overview
Adjusts TextInput key handling to match standard readline expectations on Linux while preserving macOS behaviors.
Changes:
- Routes Linux
Ctrl+Ato “start of line” instead of “select all”. - Enables word navigation/deletion via
Meta(Alt/Option) by broadening word-modifier detection (wordMod). - Updates arrow-key word movement and delete-word behaviors to respect the new word-modifier.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
On the Copilot comment re: Option+A on macOS — that's a pre-existing ambiguity in |
65fb127 to
3db5677
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 23 out of 23 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 23 out of 23 changed files in this pull request and generated no new comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
textInput treated the platform action-mod (Cmd on macOS, Ctrl on Linux) as the sole word-boundary modifier. On Linux that meant: - Ctrl+A selected all instead of jumping to line start (contra standard readline and the hotkey doc in README.md which says `Ctrl+A` = Start of line). - Alt+B / Alt+F / Alt+Backspace / Alt+Delete were dropped, because `key.meta` was never consulted — the README already documented `Meta+B` / `Meta+F` as word nav. Gate select-all to macOS Cmd+A (`isMac && mod && inp === 'a'`), route Linux Ctrl+A through `actionHome`, and broaden every word-boundary predicate (b/f/Backspace/Delete and the modified arrow keys) from `mod` to `wordMod = mod || k.meta` so Alt chords work on Linux and Mac while existing Ctrl/Cmd chords keep working.
5affa06 to
d86c886
Compare
…ne-parity-linux fix(tui): readline parity on Linux — Ctrl+A = home, Alt+B/F word nav
…ne-parity-linux fix(tui): readline parity on Linux — Ctrl+A = home, Alt+B/F word nav
…ne-parity-linux fix(tui): readline parity on Linux — Ctrl+A = home, Alt+B/F word nav
…ne-parity-linux fix(tui): readline parity on Linux — Ctrl+A = home, Alt+B/F word nav
…ne-parity-linux fix(tui): readline parity on Linux — Ctrl+A = home, Alt+B/F word nav
…ne-parity-linux fix(tui): readline parity on Linux — Ctrl+A = home, Alt+B/F word nav
From TUI blitz-test feedback: "Standard readline keys (Ctrl+A … Ctrl+K … Ctrl+W) seem not to work" / "Using ctrl-a to jump to start of line highlights all the text input" / "Some terminal navigation shortcuts that I expect don't work, such as Alt+B to navigate 'back a word'."
Summary
textInput treated the platform action-mod (Cmd on macOS, Ctrl on Linux) as the sole word-boundary modifier. On Linux that meant:
ui-tui/README.md(which documentsCtrl+A= Start of line).key.metawas never consulted, even though the README already documentsMeta+B/Meta+Fas word nav.Fix:
isMac && mod && inp === 'a'), route Linux Ctrl+A throughactionHome.modtowordMod = mod || k.metaso Alt chords work on Linux and Mac while existing Ctrl/Cmd chords keep working.Test plan
npm run type-checkcleannpm test— 152/152 pass