Fix Ctrl keybinding in terminal on Windows#1385
Fix Ctrl keybinding in terminal on Windows#1385CowgillAlex wants to merge 1 commit intopingdotgg:mainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| if (event.ctrlKey && !event.metaKey && !event.altKey) { | ||
| return moveWordCtrl; | ||
| } | ||
| return null; |
There was a problem hiding this comment.
Alt+Arrow word movement removed on non-Mac platforms
Medium Severity
The refactored else branch for non-Mac platforms only handles Ctrl+Arrow, but the previous code also handled Alt+Arrow for word movement (returning TERMINAL_WORD_BACKWARD/TERMINAL_WORD_FORWARD). That Alt+Arrow path was dropped entirely, so Alt+Arrow on Windows/Linux now returns null instead of sending the word-movement escape sequence. On Linux, Alt+Arrow is a common way to navigate by word in terminals, making this a functional regression that doesn't appear to be intentional based on the PR description.
There was a problem hiding this comment.
Pull request overview
Adjusts terminal navigation key handling so Ctrl+Left/Right produces the expected escape sequences (not literal b/f characters) for word-wise cursor movement, targeting Windows terminal behavior in the web app’s xterm-based terminal.
Changes:
- Added CSI escape sequences for Ctrl+Arrow word navigation (
\u001b[1;5D/\u001b[1;5C). - Updated
terminalNavigationShortcutDatato return these sequences for non-macOS Ctrl+Arrow. - Updated unit tests to assert the new sequences.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| apps/web/src/keybindings.ts | Adds Ctrl+Arrow escape sequences and changes non-macOS mapping logic in terminalNavigationShortcutData. |
| apps/web/src/keybindings.test.ts | Updates expectations for non-macOS Ctrl+Arrow mappings to the new CSI sequences. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } else { | ||
|
|
||
| if (event.ctrlKey && !event.metaKey && !event.altKey) { | ||
| return moveWordCtrl; | ||
| } | ||
| return null; |
There was a problem hiding this comment.
This change alters behavior for all non-macOS platforms (including Linux), even though the PR title scopes the fix to Windows. If only Windows needs the CSI sequences, consider gating the ctrlKey mapping to Windows platforms (or update the PR title/description to reflect the broader behavior change).
|
|
||
| if (event.ctrlKey && !event.metaKey && !event.altKey) { | ||
| return moveWordCtrl; | ||
| } | ||
| return null; |
There was a problem hiding this comment.
On non-macOS, Alt+ArrowLeft/Right is no longer handled at all (previously it mapped to TERMINAL_WORD_*). If dropping Alt-based word navigation is not intentional, reintroduce an altKey branch for non-macOS; otherwise, add an explicit test/assertion documenting that altKey is unsupported on non-macOS to avoid accidental regressions.
| @@ -280,15 +285,12 @@ export function terminalNavigationShortcutData( | |||
| return moveLine; | |||
| } | |||
| return null; | |||
| } else { | |||
|
|
|||
| if (event.ctrlKey && !event.metaKey && !event.altKey) { | |||
| return moveWordCtrl; | |||
| } | |||
There was a problem hiding this comment.
There’s some inconsistent formatting in the newly added code (a very long moveWordCtrl line and a blank line inside the else block). Running the formatter / wrapping moveWordCtrl similarly to moveWord/moveLine will keep style consistent and avoid trailing whitespace.
| it("maps Ctrl+Arrow on non-macOS to word movement", () => { | ||
| assert.strictEqual( | ||
| terminalNavigationShortcutData(event({ key: "ArrowLeft", ctrlKey: true }), "Win32"), | ||
| "\u001bb", | ||
| "\u001b[1;5D", | ||
| ); | ||
| assert.strictEqual( | ||
| terminalNavigationShortcutData(event({ key: "ArrowRight", ctrlKey: true }), "Linux"), | ||
| "\u001bf", | ||
| "\u001b[1;5C", | ||
| ); |
There was a problem hiding this comment.
The updated expectations now use the CSI Ctrl+Arrow sequences for both Win32 and Linux, but the test name still reads as a single generic non-macOS case. Consider splitting this into explicit platform-specific assertions (e.g., Windows vs Linux) or adding a case for non-macOS altKey behavior (supported vs unsupported) so the intended cross-platform contract is clear.
What Changed
Changed
keybindings.tsand its test to properly handlectrl + rightArrow,ctrl + leftArrow.Why
Currently the terminal interprets
ctrl + right arrowandctrl + left arrowon Windows asbandf, rather than moving the caret to the next/previous word. This fixes that to no longer interpret the sequence asbandfI assume that Linux keyboards would handle the terminal ctrl inputs in the same way
UI Changes
Before:
t3code.before.mp4
t3code.after.mp4
Checklist
Note
Low Risk
Low risk: small, localized change to terminal escape sequences for non-macOS Ctrl+Arrow navigation, covered by updated unit tests.
Overview
Fixes non-macOS terminal word navigation so
Ctrl+ArrowLeft/Rightemits the expected control-modified arrow escape sequences (\u001b[1;5D/\u001b[1;5C) instead ofAlt-style word jumps.Updates
terminalNavigationShortcutDatato return the new sequences only forCtrl+Arrowon Windows/Linux, and adjusts tests to assert the corrected output.Written by Cursor Bugbot for commit 30f0822. This will update automatically on new commits. Configure here.
Note
Fix Ctrl+Arrow keybindings in terminal on Windows
On non-macOS,
Ctrl+ArrowLeft/Rightnow sends\u001b[1;5D/\u001b[1;5C(standard xterm control sequences for word movement) instead of the previously used\u001bb/\u001bf(which are Alt/Option-based sequences).Alt+Arrowon non-macOS no longer produces a word-move sequence and now returns null. macOS behavior (Option+Arrow for word, Cmd+Arrow for line) is unchanged.Macroscope summarized 30f0822.