You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In nvim normal mode, while typing with a CJK system input method and the composition is still uncommitted (characters typed, no candidate picked yet), switching the input method (Caps Lock or Fn) inserts the uncommitted characters directly into the buffer. In other words, text gets inserted while I'm in normal mode.
On other terminals (Terminal.app, WezTerm, etc.) the uncommitted characters are instead sent as key events, so nvim reads them as normal-mode commands. Example: type jjjj, then switch input
method: on other terminals the cursor moves down four lines, while on Ghostty jjjj gets inserted into the buffer.
Expected Behavior
On an input-method switch, the uncommitted characters should reach nvim as normal key input, so nvim interprets them in its current mode. In normal mode that means they run as commands, the same as Terminal.app and WezTerm.
wezterm2026-07-05.12.29.23.mov
Actual Behavior
In nvim normal mode, while typing with a CJK system input method and the composition is still uncommitted (characters typed, no candidate picked yet), switching the input method (Caps Lock or Fn) inserts the uncommitted characters directly into the buffer. In other words, text gets inserted while I'm in normal mode.
2026-07-05.12.26.27.mov
Reproduction Steps
Open Ghostty and start nvim.
Make sure you're in normal mode.
Switch to a system CJK input method.
Type jjj so a composition is active (candidate window open, nothing committed yet).
Switch the input method with Fn or Caps Lock.
Result: jjj gets inserted into the buffer.
Expected: it's handled as normal-mode commands (cursor moves down three lines), as on Terminal.app / WezTerm.
Ghostty Logs
No response
Ghostty Version
Ghostty 1.3.2-main-+8642142a3
Version
- version: 1.3.2-main-+8642142a3
- channel: tip
Build Config
- Zig version : 0.15.2
- build mode : .ReleaseFast
- app runtime : .none
- font engine : .coretext
- renderer : renderer.generic.Renderer(renderer.Metal)
- libxev : kqueue
OS Version Information
Darwin Kernel Version 25.5.0 macOS Tahoe 26.5.1 (25F80) arm64
(Linux only) Display Server
None
(Linux only) Desktop Environment/Window Manager
No response
Minimal Ghostty Configuration
--config-default-files=false
Additional Relevant Configuration
neovim with any version( I tried in 0.10.* ~ 0.12.*, all repro )
I acknowledge that:
I have reviewed the FAQ and confirm that my issue is NOT among them.
I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.
Discussed in #13193
Originally posted by Nagato-Yuzuru July 5, 2026
Issue Description
In nvim normal mode, while typing with a CJK system input method and the composition is still uncommitted (characters typed, no candidate picked yet), switching the input method (Caps Lock or Fn) inserts the uncommitted characters directly into the buffer. In other words, text gets inserted while I'm in normal mode.
On other terminals (Terminal.app, WezTerm, etc.) the uncommitted characters are instead sent as key events, so nvim reads them as normal-mode commands. Example: type jjjj, then switch input
method: on other terminals the cursor moves down four lines, while on Ghostty jjjj gets inserted into the buffer.
Expected Behavior
On an input-method switch, the uncommitted characters should reach nvim as normal key input, so nvim interprets them in its current mode. In normal mode that means they run as commands, the same as Terminal.app and WezTerm.
wezterm2026-07-05.12.29.23.mov
Actual Behavior
In nvim normal mode, while typing with a CJK system input method and the composition is still uncommitted (characters typed, no candidate picked yet), switching the input method (Caps Lock or Fn) inserts the uncommitted characters directly into the buffer. In other words, text gets inserted while I'm in normal mode.
2026-07-05.12.26.27.mov
Reproduction Steps
Result: jjj gets inserted into the buffer.
Expected: it's handled as normal-mode commands (cursor moves down three lines), as on Terminal.app / WezTerm.
Ghostty Logs
No response
Ghostty Version
OS Version Information
Darwin Kernel Version 25.5.0 macOS Tahoe 26.5.1 (25F80) arm64
(Linux only) Display Server
None
(Linux only) Desktop Environment/Window Manager
No response
Minimal Ghostty Configuration
--config-default-files=falseAdditional Relevant Configuration
neovim with any version( I tried in 0.10.* ~ 0.12.*, all repro )
I acknowledge that:
```) on separate lines.