Match Cmd shortcuts on the ASCII-capable layout under non-Latin input sources

[AndrewDongminYoo]

Description

On macOS, a Cmd shortcut that is not also a menu item did nothing while a keyboard layout that is not ASCII-capable was active. #8547 reports it for the Terminal/Agent input mode toggle (⌘I) under the Korean 2-Set input source; it works again as soon as the user switches to an English input source.

The key of a keystroke came from NSEvent.charactersIgnoringModifiers, which reports the active layout's own character even with Cmd held. Measured with locally constructed NSEvents under Korean 2-Set, Cmd+I reports characters = "i" but charactersIgnoringModifiers = "ㅑ", so the keystroke became cmd-ㅑ and never matched cmd-i. from_native in crates/warpui/src/platform/mac/event.rs is the only place this conversion happens, and both keyDown: and the performKeyEquivalent: binding checks go through it.

For a Cmd keystroke whose reported character is not ASCII, the key now comes from translating the key code through the current ASCII-capable keyboard layout (TISCopyCurrentASCIICapableKeyboardLayoutInputSource), with Shift applied. That reproduces what the English input source reports for the same key, including shifted symbols: under Korean 2-Set the translation gives i, I, ! and { for Cmd+I, Cmd+Shift+I, Cmd+Shift+1 and Cmd+Shift+[, the same keys the ABC layout reports. Everything else takes the path it took before:

• The lookup returns nothing when the current layout is already ASCII-capable, so Latin layouts keep their own characters (cmd-ö on German stays cmd-ö).
• Named keys (arrows, function keys), keystrokes without Cmd, and ASCII characters are untouched, so typing and Option combinations do not change.

The decision is a pure keystroke_key function with unit tests in a sibling event_tests.rs; the key code translation is a new keyCodeToAsciiCapableChar beside keyCodeToChar in keycode.m.

Scope and related work

• Ctrl is deliberately left alone. The draft macOS: match Ctrl-modified chords on physical key, not IME character (CSAT-10277 / GH#15196) #15197 handles Ctrl chords under the same input source in the same function, by mapping the physical key to US-QWERTY the way the Windows fix (Fix chord shortcuts on Windows non-Latin keyboard layouts #9476, us_qwerty_fallback_for_chord) does. The modifier gate here is a single condition, so the two can be reconciled whichever lands first.
• Related: Keybindings don't trigger on non-US input sources - international i18n ime international keyboards #341 (shortcuts on non-US input sources) and Shortcuts doesn‘t work with non-latin alphabet input sources #8682 (Cmd+Shift+[ under Russian and Japanese input sources). I have only verified Korean 2-Set, so this PR does not claim to close either.
• Known limitation, pre-existing: if a Hangul syllable is still being composed when a Cmd shortcut fires, the syllable is dropped, because keyDownImpl in host_view.m inserts IME-committed text only when the key was not handled. This already happens today with ⌘↵, which matched under Korean before this change (type 안녕하 and press ⌘↵: only 안녕 remains). This PR extends the set of Cmd shortcuts that work under Korean, and so the set that can hit it; fixing it means inserting committed text before the shortcut runs, which changes the event order for all IME input, so I would rather do it separately.
• A user who rebound an action to a layout character such as cmd-ㅑ stops matching it.
• Left unchanged: details.key_without_modifiers still reports the layout character (the kitty keyboard protocol path, see macOS: kitty keyboard protocol never reports the base layout key, so Ctrl+<letter> is unmatchable on non-Latin layouts #15646), and global hotkeys resolve through charToKeyCodes, which is built from the layout active at its first call.

The hint half of #8547

The issue also reports a ⌘Space hint that stays visible after turning off "Show input hint text". Neither the installed stable build nor this branch shows a ⌘Space hint any more; the message line now reads ⌘↵ new /agent conversation, derived from the binding. That line is controlled by the "terminal input message line" setting, not "Show input hint text", which only controls the input placeholder. So the remaining behavior is two separate settings rather than a bug, and I have not changed it here.

Linked Issue

Closes #8547.

• The linked issue is labeled ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Testing

• cargo nextest run -p warpui --lib -E 'test(/platform::mac::event::tests/)': 6 passed. With the fallback disabled, a_command_keystroke_on_a_non_latin_letter_takes_the_ascii_capable_key fails, as it should.
• cargo fmt -p warpui -- --check, cargo clippy -p warpui --all-targets --tests -- -D warnings, ./script/check_no_inline_test_modules: passed.
• keycode.m was formatted by hand to match the surrounding code, since clang-format is not installed on this machine. ./script/presubmit was not run in full for the same reason (it also needs wgslfmt and pwsh).

Manual testing with ./script/run, logged in, macOS with the ABC and Korean 2-Set input sources:

1. Installed stable Warp: ⌘I toggles Agent ↔ Terminal input mode under ABC, and does nothing under Korean 2-Set.
2. This branch: ⌘I toggles in both directions under both ABC and Korean 2-Set.
3. This branch, Korean 2-Set: ⌘T opens exactly one tab, so menu shortcuts are not dispatched twice.
4. This branch, Korean 2-Set: pressing ⌘I while 하 is still composing toggles the mode and drops 하 (the pre-existing limitation above).

• I have manually tested my changes locally with ./script/run

Screenshots / Videos

The recording follows the four manual steps under Testing, in order. The input source indicator in the menu bar shows which source is active in each segment: the installed stable Warp first, then the WarpOss build of this branch.
Keystrokes are not overlaid on screen; in each segment the key pressed is the one named in the matching Testing step (⌘I, or ⌘T in step 3), and the mode or tab change that follows is its result.

Screen.Recording.2026-09-29.at.9.31.22.AM.mov

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

CHANGELOG-BUG-FIX: Cmd keyboard shortcuts such as ⌘I now work on macOS while a non-Latin input source such as Korean 2-Set is active.

[warp-for-oss]

@AndrewDongminYoo

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @acarl005.

Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[warp-for-oss]

Overview

This PR updates macOS key event conversion so Command shortcuts under non-Latin input sources can fall back to the current ASCII-capable keyboard layout, while preserving existing behavior for named keys, non-Command input, ASCII characters, and ASCII-capable layouts. The change includes focused unit coverage for the new keystroke-key decision logic.

Concerns

• No blocking correctness, security, comment-quality, test-quality, or spec-drift concerns found in the annotated diff.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[acarl005]

Sorry for the confusion. Issue #8547 should've been marked as a duplicate and it's certainly not ready-to-implement. International keybindings is a very difficult problem and we can't accept outside contributions for it.

[AndrewDongminYoo]

Thanks for the clear answer, and no problem. I'll stay out of the keybinding area.

In case it is useful to whoever picks this up internally (it overlaps with the draft #15197 in the same from_native function), two things I measured on macOS with Korean 2-Set, using locally constructed NSEvents:

• Cmd+I reports characters = "i" but charactersIgnoringModifiers = "ㅑ", and Ctrl+I also reports ㅑ, so any Cmd or Ctrl binding that is not also a menu item misses.
• Separately, and already on stable: keyDownImpl inserts IME-committed text only when the key was not handled, so a syllable still being composed when a shortcut fires is dropped. Typing 안녕하 and pressing ⌘↵ leaves only 안녕.

I'll leave the branch on my fork in case any of it helps.