Word navigation misses CJK/ASCII boundaries after IME input

[Toukou-Yuu]

Description

Word navigation for mixed CJK and ASCII text depends on how the text was entered.

For the same visible text: 你好hello世界

Actual behavior

When the complete text is pasted from the clipboard, Ctrl+Left / Ctrl+Right recognizes these boundaries:

• Clipboard paste: |你好|hello|世界|

When the same text is entered through an IME, the entire string is treated as one word:

• IME input: |你好hello世界|

Expected behavior

Both input methods should produce the same boundaries:

• Expected: |你好|hello|世界|

Forward and backward navigation should use the same boundaries. The visible text is identical, so its word boundaries should not depend on whether it was pasted or entered through an IME.

Investigation

OpenTUI PR #719 introduced CJK/ASCII word classes and detects script transitions within a text-buffer chunk.

However, IME commits can create separate rope chunks, and OpenTUI 0.4.5 does not preserve the previous word class while navigating across those chunks. As a result, transitions inside pasted text are detected, while transitions between IME-created chunks are missed.

OpenTUI PR #1428 later added cross-chunk word-class tracking for forward and backward word navigation. That fix is included in OpenTUI v0.5.9 and later.

OpenCode 1.18.26 still uses @opentui/core, @opentui/keymap, and @opentui/solid version 0.4.5, so the upstream fix is not present in the current OpenCode release.

I verified this in a clean worktree based on OpenCode dev commit 51f86c8537. With no OpenCode word-navigation changes, upgrading @opentui/core, @opentui/keymap, and @opentui/solid from 0.4.5 to 0.5.9 made both clipboard paste and IME input produce the expected boundaries: |你好|hello|世界|.

The TUI, plugin, and OpenCode source type checks pass after the upgrade. I did not find an upgrade-specific regression during local Windows testing, although full cross-platform compatibility still needs to be confirmed by CI.

This confirms that the issue can be resolved by upgrading OpenTUI rather than adding OpenCode-specific word-navigation logic.

Scope

This issue is only about consistent CJK/ASCII transition boundaries. It does not propose changing how consecutive CJK text is segmented into natural-language words.

Related original OpenTUI report:

• bug: ctrl+w (deleteWordBackward) doesn't recognize word boundaries between CJK and ASCII characters opentui#596

Plugins

None

OpenCode version

1.18.26; also reproduced on dev 1.18.28 at 51f86c8 with OpenTUI 0.4.5

Steps to reproduce

1. Open the OpenCode TUI.
2. Paste 你好hello世界 from the clipboard.
3. Use Ctrl+Left and Ctrl+Right to navigate through the text.
4. Observe that the text has the expected boundaries: |你好|hello|世界|.
5. Clear the input.
6. Enter 你好, hello, and 世界 through an IME so that the final visible text is again 你好hello世界.
7. Use Ctrl+Left and Ctrl+Right again.
8. Observe that the entire string is treated as one word: |你好hello世界|.

Screenshot and/or share link

The following recording compares word navigation after clipboard paste and IME input:

Operating System

Windows 11 Pro, version 10.0.26200 (build 26200)

Terminal

Visual Studio Code integrated terminal (PowerShell) and Windows Terminal (PowerShell)