macOS: switching input source during CJK composition inserts the uncommitted text instead of sending it as keys (breaks nvim normal mode)

[Nagato-Yuzuru]

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

1. Open Ghostty and start nvim.
2. Make sure you're in normal mode.
3. Switch to a system CJK input method.
4. Type jjj so a composition is active (candidate window open, nothing committed yet).
5. 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.1

Version
  - version: 1.3.1
  - channel: stable
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.

[Nagato-Yuzuru]

I've read the code. I think the root cause is that switching the input source commits the preedit through the text path (ghostty_surface_text) instead of the key path (ghostty_surface_key).

Ghostty sends input to the pty two ways:

• ghostty_surface_key: a key event the app interprets in its current mode (in nvim normal mode, j moves down).
• ghostty_surface_text: text, which a bracketed-paste-aware app like nvim inserts literally, whatever the mode.

Normal preedit commits happen inside keyDown and use the key path. committedPreeditTextAction (SurfaceView_AppKit.swift:1492) sends the committed text via ghostty_surface_key, so nvim interprets it per mode. That part is correct.

When you switch input source mid-composition, the IME force-commits the preedit by calling insertText outside a keyDown. keyTextAccumulator is nil, so it falls through to sendText (SurfaceView_AppKit.swift:2056) → ghostty_surface_text (Ghostty.Surface.swift:41). The uncommitted reading goes out as pasted text and nvim inserts it, instead of going out as keys nvim would interpret. That's jjjj getting inserted vs. jjjj moving the cursor down.

I haven't built it to confirm the exact runtime call, but the two paths match the observed behavior.

A fix would likely route the out-of-keyDown preedit commit through the key path, the way committedPreeditTextAction already does, instead of sendText, with a guard so genuine text insertion (dictation, emoji viewer) still uses ghostty_surface_text.

[bo2themax]

duplicate of #12278

[Nagato-Yuzuru]

I see and commented that. Actually, this describes two issues; I'm not sure if they share a common root cause.

#12278 describes whether the text will be displayed in the terminal when the input method is typing but no word has been selected.

This issue describes how “switching input methods causes ‘ghostty_surface_text’ to behave the same as pasted text, resulting in unexpected text insertion in nvim normal mode.”

In my tests, this behaves of #12278 same as wezterm and Terminal.app.

2026-07-05.16.29.48.mov

[bo2themax]

OK, make sense, i just opened my laptop and tested this, tip version doesn't seem to have this issue any more, it should be fixed by #12547

[Nagato-Yuzuru]

Thanks. I tested today's tip build with the exact steps above (nvim insert text in normal) and still get it.

The version is:

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

This looks separate from #12278.

Could this be moved to an issue? I already dug into the code path (comment above) and I'd like to take a shot at fixing it.

[bo2themax]

#13195