gpui: Complete pending key bindings before IME input by GoldStrikeArch · Pull Request #61270 · zed-industries/zed

GoldStrikeArch · 2026-07-18T20:04:59Z

Objective

Fix multi-stroke keybindings such as ctrl-x k being intercepted by the macOS Japanese IME before GPUI can complete the binding.
Preserve IME-first handling for ordinary Japanese text input and active marked-text composition.
Fixes 2-stroke keybindings (e.g., ctrl-x k) fail when macOS Input Method is ON since v0.230.0 #56043.

Solution

Stop preferring IME-first printable input while a valid multi-stroke keybinding is pending. This allows the next printable keystroke to reach GPUI and complete the binding.
Consider pending input active only when it belongs to the window's current focus. This prevents stale pending state after a focus change or blur from bypassing normal IME handling.
Preserve the existing macOS active-composition path, so marked text, candidate selection, and composition commands continue to reach NSTextInputContext first.

Testing

Manually tested on macOS using Apple’s built-in Japanese–Romaji/Hiragana input source with a ctrl-x k keybinding. Also added regression test for pending keybinding routing.

Self-Review Checklist:

I've reviewed my own diff for quality, security, and reliability
Unsafe blocks (if any) have justifying comments
The content adheres to Zed's UI standards (UX/UI and icon guidelines)
Tests cover the new/changed behavior
Performance impact has been considered and is acceptable

Release Notes:

Fixed multi-stroke keybindings not completing when using an IME on macOS.

opsnull · 2026-07-25T15:27:48Z

Thanks @GoldStrikeArch! This PR also resolved my Chinese IME problems.

# Objective Fixes zed-industries#59129. `vim::HelixJumpToWord` currently treats its two-character target labels as text input. When an IME is active, the printable label keys can therefore enter the IME composition window instead of completing the jump. ## Solution - Treat an active Helix jump as command input rather than character input, preventing the platform input handler from preferring the IME for its label keys. - After normal keybinding resolution, handle action-less, unmodified label keydowns directly from the keystroke's ASCII-equivalent key. This preserves label matching on non-ASCII keyboard layouts while leaving Escape, custom bindings, and Ctrl/Alt/Cmd/Function shortcuts untouched. - Stop propagation after consuming a label key so the platform does not subsequently forward it to the IME. - Keep the existing committed-text handling as a fallback for other input paths. This is complementary to zed-industries#61270: that PR handles pending GPUI keybinding chords before IME input, while this change handles Helix jump labels after the initiating action has resolved. The changes are also file-disjoint. ## Testing - Added a regression test using the issue's `s` → `vim::HelixJumpToWord` binding. The test verifies that: - no GPUI keybinding chord is pending; - Helix jump does not accept text input or prefer the IME; - both raw label keydown events are consumed; and - the expected jump completes. - Manually tested on macOS with both ABC and Japanese Romaji input sources. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed Helix jump-to-word label input being intercepted by IMEs.

`has_pending_keystrokes` only reports pending input belonging to the current focus, but `pending_input_keystrokes` still returned the keystrokes of input left over from a previous focus, so the two disagreed after a blur. Route both through one accessor so that they cannot drift apart. Also document that `query_prefers_ime_for_printable_keys` is gated on pending input rather than purely delegating to the handler, as its name suggests.

tomhoule

I can also confirm the fix works from manual testing, and I think the way it works is sound. Thank you for the contribution!

…61270) # Objective - Fix multi-stroke keybindings such as `ctrl-x k` being intercepted by the macOS Japanese IME before GPUI can complete the binding. - Preserve IME-first handling for ordinary Japanese text input and active marked-text composition. - Fixes zed-industries#56043. ## Solution - Stop preferring IME-first printable input while a valid multi-stroke keybinding is pending. This allows the next printable keystroke to reach GPUI and complete the binding. - Consider pending input active only when it belongs to the window's current focus. This prevents stale pending state after a focus change or blur from bypassing normal IME handling. - Preserve the existing macOS active-composition path, so marked text, candidate selection, and composition commands continue to reach `NSTextInputContext` first. ## Testing Manually tested on macOS using Apple’s built-in Japanese–Romaji/Hiragana input source with a `ctrl-x k` keybinding. Also added regression test for pending keybinding routing. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed multi-stroke keybindings not completing when using a Japanese IME on macOS. --------- Co-authored-by: Tom Houlé <tom@tomhoule.com> (cherry picked from commit dc1e815)

# Objective Fixes zed-industries#59129. `vim::HelixJumpToWord` currently treats its two-character target labels as text input. When an IME is active, the printable label keys can therefore enter the IME composition window instead of completing the jump. ## Solution - Treat an active Helix jump as command input rather than character input, preventing the platform input handler from preferring the IME for its label keys. - After normal keybinding resolution, handle action-less, unmodified label keydowns directly from the keystroke's ASCII-equivalent key. This preserves label matching on non-ASCII keyboard layouts while leaving Escape, custom bindings, and Ctrl/Alt/Cmd/Function shortcuts untouched. - Stop propagation after consuming a label key so the platform does not subsequently forward it to the IME. - Keep the existing committed-text handling as a fallback for other input paths. This is complementary to zed-industries#61270: that PR handles pending GPUI keybinding chords before IME input, while this change handles Helix jump labels after the initiating action has resolved. The changes are also file-disjoint. ## Testing - Added a regression test using the issue's `s` → `vim::HelixJumpToWord` binding. The test verifies that: - no GPUI keybinding chord is pending; - Helix jump does not accept text input or prefer the IME; - both raw label keydown events are consumed; and - the expected jump completes. - Manually tested on macOS with both ABC and Japanese Romaji input sources. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed Helix jump-to-word label input being intercepted by IMEs.

…61270) # Objective - Fix multi-stroke keybindings such as `ctrl-x k` being intercepted by the macOS Japanese IME before GPUI can complete the binding. - Preserve IME-first handling for ordinary Japanese text input and active marked-text composition. - Fixes zed-industries#56043. ## Solution - Stop preferring IME-first printable input while a valid multi-stroke keybinding is pending. This allows the next printable keystroke to reach GPUI and complete the binding. - Consider pending input active only when it belongs to the window's current focus. This prevents stale pending state after a focus change or blur from bypassing normal IME handling. - Preserve the existing macOS active-composition path, so marked text, candidate selection, and composition commands continue to reach `NSTextInputContext` first. ## Testing Manually tested on macOS using Apple’s built-in Japanese–Romaji/Hiragana input source with a `ctrl-x k` keybinding. Also added regression test for pending keybinding routing. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed multi-stroke keybindings not completing when using a Japanese IME on macOS. --------- Co-authored-by: Tom Houlé <tom@tomhoule.com>

…61270) # Objective - Fix multi-stroke keybindings such as `ctrl-x k` being intercepted by the macOS Japanese IME before GPUI can complete the binding. - Preserve IME-first handling for ordinary Japanese text input and active marked-text composition. - Fixes zed-industries#56043. ## Solution - Stop preferring IME-first printable input while a valid multi-stroke keybinding is pending. This allows the next printable keystroke to reach GPUI and complete the binding. - Consider pending input active only when it belongs to the window's current focus. This prevents stale pending state after a focus change or blur from bypassing normal IME handling. - Preserve the existing macOS active-composition path, so marked text, candidate selection, and composition commands continue to reach `NSTextInputContext` first. ## Testing Manually tested on macOS using Apple’s built-in Japanese–Romaji/Hiragana input source with a `ctrl-x k` keybinding. Also added regression test for pending keybinding routing. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed multi-stroke keybindings not completing when using a Japanese IME on macOS. --------- Co-authored-by: Tom Houlé <tom@tomhoule.com> (cherry picked from commit dc1e815)

# Objective Fixes zed-industries#59129. `vim::HelixJumpToWord` currently treats its two-character target labels as text input. When an IME is active, the printable label keys can therefore enter the IME composition window instead of completing the jump. ## Solution - Treat an active Helix jump as command input rather than character input, preventing the platform input handler from preferring the IME for its label keys. - After normal keybinding resolution, handle action-less, unmodified label keydowns directly from the keystroke's ASCII-equivalent key. This preserves label matching on non-ASCII keyboard layouts while leaving Escape, custom bindings, and Ctrl/Alt/Cmd/Function shortcuts untouched. - Stop propagation after consuming a label key so the platform does not subsequently forward it to the IME. - Keep the existing committed-text handling as a fallback for other input paths. This is complementary to zed-industries#61270: that PR handles pending GPUI keybinding chords before IME input, while this change handles Helix jump labels after the initiating action has resolved. The changes are also file-disjoint. ## Testing - Added a regression test using the issue's `s` → `vim::HelixJumpToWord` binding. The test verifies that: - no GPUI keybinding chord is pending; - Helix jump does not accept text input or prefer the IME; - both raw label keydown events are consumed; and - the expected jump completes. - Manually tested on macOS with both ABC and Japanese Romaji input sources. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed Helix jump-to-word label input being intercepted by IMEs.

…61270) # Objective - Fix multi-stroke keybindings such as `ctrl-x k` being intercepted by the macOS Japanese IME before GPUI can complete the binding. - Preserve IME-first handling for ordinary Japanese text input and active marked-text composition. - Fixes zed-industries#56043. ## Solution - Stop preferring IME-first printable input while a valid multi-stroke keybinding is pending. This allows the next printable keystroke to reach GPUI and complete the binding. - Consider pending input active only when it belongs to the window's current focus. This prevents stale pending state after a focus change or blur from bypassing normal IME handling. - Preserve the existing macOS active-composition path, so marked text, candidate selection, and composition commands continue to reach `NSTextInputContext` first. ## Testing Manually tested on macOS using Apple’s built-in Japanese–Romaji/Hiragana input source with a `ctrl-x k` keybinding. Also added regression test for pending keybinding routing. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed multi-stroke keybindings not completing when using a Japanese IME on macOS. --------- Co-authored-by: Tom Houlé <tom@tomhoule.com>

cla-bot Bot added the cla-signed The user has signed the Contributor License Agreement label Jul 18, 2026

GoldStrikeArch mentioned this pull request Jul 19, 2026

vim: Handle Helix jump labels before IME input #61315

Merged

5 tasks

ChristopherBiscardi added the area:gpui GPUI rendering framework support label Jul 21, 2026

tomhoule self-assigned this Jul 28, 2026

GoldStrikeArch and others added 2 commits July 29, 2026 14:13

gpui: Complete pending key bindings before IME input

419f81c

tomhoule force-pushed the fix/pending-key-input-during-ime-input branch from 02cdb8d to 0623a44 Compare July 29, 2026 13:14

tomhoule approved these changes Jul 29, 2026

View reviewed changes

tomhoule added this pull request to the merge queue Jul 29, 2026

Merged via the queue into zed-industries:main with commit dc1e815 Jul 29, 2026
36 checks passed

GoldStrikeArch deleted the fix/pending-key-input-during-ime-input branch July 29, 2026 15:38

github-actions Bot mentioned this pull request Aug 6, 2026

🎨 Zed GPUI Release Tracker gpui-archipelago/gpui-release-notes#3

Open

Sha1rholder mentioned this pull request Aug 17, 2026

Pending multi-stroke keybindings (Ctrl+K) are intercepted by IME #62764

Open

Navigation Menu

Uh oh!

Uh oh!

gpui: Complete pending key bindings before IME input - #61270

gpui: Complete pending key bindings before IME input#61270
tomhoule merged 2 commits into
zed-industries:mainfrom
GoldStrikeArch:fix/pending-key-input-during-ime-input

GoldStrikeArch commented Jul 18, 2026 •

edited by tomhoule

Loading

Uh oh!

opsnull commented Jul 25, 2026 •

edited

Loading

Uh oh!

tomhoule left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

GoldStrikeArch commented Jul 18, 2026 • edited by tomhoule Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Testing

Self-Review Checklist:

Uh oh!

opsnull commented Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tomhoule left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

GoldStrikeArch commented Jul 18, 2026 •

edited by tomhoule

Loading

opsnull commented Jul 25, 2026 •

edited

Loading