Skip to content

Fix Ctrl keybinding in terminal on Windows #1385

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
CowgillAlex wants to merge 1 commit into
base: main
Choose a base branch
from
+16 −14
Open

Fix Ctrl keybinding in terminal on Windows #1385

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions apps/web/src/keybindings.test.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -439,11 +439,11 @@ describe("terminalNavigationShortcutData", () => {
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",
);
Comment on lines 439 to 447
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copilot uses AI. Check for mistakes.
});

Expand Down
26 changes: 14 additions & 12 deletions apps/web/src/keybindings.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,8 @@ interface ShortcutMatchOptions {

const TERMINAL_WORD_BACKWARD = "\u001bb";
const TERMINAL_WORD_FORWARD = "\u001bf";
const TERMINAL_WORD_BACKWARD_CTRL = "\u001b[1;5D";
const TERMINAL_WORD_FORWARD_CTRL = "\u001b[1;5C";
const TERMINAL_LINE_START = "\u0001";
const TERMINAL_LINE_END = "\u0005";

Expand Down Expand Up @@ -269,8 +271,11 @@ export function terminalNavigationShortcutData(
return null;
}

const moveWord = key === "arrowleft" ? TERMINAL_WORD_BACKWARD : TERMINAL_WORD_FORWARD;
const moveLine = key === "arrowleft" ? TERMINAL_LINE_START : TERMINAL_LINE_END;
const moveWord =
key === "arrowleft" ? TERMINAL_WORD_BACKWARD : TERMINAL_WORD_FORWARD;
const moveLine =
key === "arrowleft" ? TERMINAL_LINE_START : TERMINAL_LINE_END;
const moveWordCtrl = key === "arrowleft" ? TERMINAL_WORD_BACKWARD_CTRL : TERMINAL_WORD_FORWARD_CTRL;

if (isMacPlatform(platform)) {
if (event.altKey && !event.metaKey && !event.ctrlKey) {
Expand All @@ -280,15 +285,12 @@ export function terminalNavigationShortcutData(
return moveLine;
}
return null;
} else {

if (event.ctrlKey && !event.metaKey && !event.altKey) {
return moveWordCtrl;
}
Comment on lines 274 to +292
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copilot uses AI. Check for mistakes.
return null;
Copy link
Contributor

@cursor cursor bot Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Fix in Cursor Fix in Web

Comment on lines +288 to +293
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copilot uses AI. Check for mistakes.
Comment on lines +289 to +293
Copy link

Copilot AI Mar 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copilot uses AI. Check for mistakes.
}

if (event.ctrlKey && !event.metaKey && !event.altKey) {
return moveWord;
}

if (event.altKey && !event.metaKey && !event.ctrlKey) {
return moveWord;
}

return null;

}
Loading