fix(tui): correct pasted preview replacement for CJK and multi-width characters

[AbigailJixiangyuyu]

Issue for this PR

Closes #17032

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Fix a TUI bug where [Pasted ~N lines] preview tokens are not correctly replaced when the prompt contains CJK characters before the paste.

The previous implementation used terminal visual column offsets but performed the replacement using JavaScript string slicing. This works for ASCII input but becomes misaligned for multi-width characters such as Chinese, Japanese and Korean.

This PR converts the visual column offsets to the correct string indices before performing the replacement, ensuring the preview token is fully replaced by the actual pasted content.

This issue is particularly important for users typing CJK characters, since the incorrect truncation could leak part of the paste preview token into the submitted prompt, resulting in a polluted prompt.

How did you verify your code works?

Tested locally with bun dev ..

Reproduction steps:

1. Enter Chinese text in the prompt.
2. Paste multi-line content so [Pasted ~N lines] appears.
3. Submit the prompt.

Before the fix, part of the preview token could appear in the submitted prompt.
After the fix, the preview is correctly replaced with the pasted content.

Tested with:

• ASCII input
• Chinese input

Screenshots / recordings

TUI after the fix:

• Pasted multi-line content is previewed correctly in the input area.
• After sending, the submitted prompt no longer contains leaked [Pasted ~N lines] fragments when the input includes CJK characters.
• Verified with Chinese input and multi-line paste in the TUI.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[getbug]

there's still a problem when using your commit codes, when input chinese, you can forcus the cursor to a gap between two words, is easy when using mouse, not left or right buttun。then "[" will be included in submitted input

[AbigailJixiangyuyu]

there's still a problem when using your commit codes, when input chinese, you can forcus the cursor to a gap between two words, is easy when using mouse, not left or right buttun。then "[" will be included in submitted input

Thanks for testing this.

I’m not sure I fully understand the exact reproduction steps yet.

Could you provide a more detailed step-by-step reproduction example?

A short screen recording or before/after example would also help a lot.

[getbug]

there's still a problem when using your commit codes, when input chinese, you can forcus the cursor to a gap between two words, is easy when using mouse, not left or right buttun。then "[" will be included in submitted input

Thanks for testing this.

I’m not sure I fully understand the exact reproduction steps yet.

Could you provide a more detailed step-by-step reproduction example?

A short screen recording or before/after example would also help a lot.

看你的昵称应该是中国人，我就用中文来描述现象吧，这边因为信息安全原因没法发图片，我用文字描述一下步骤吧
1、在输入框输入“快捷键测试用例”
2、用鼠标将光标点击到“键”、“测”之间，此时光标会选中“键”的右半边，“测”的左半边
3、粘贴几行文字，在“键”、“测”之间就插入了“[Pasted ~10 lines”
4、回车提交
5、在会话框，看到显示的文字是 “快捷键[....测试用例” （其中...是粘贴的多行内容），可看到展示的内容多了个[

[AbigailJixiangyuyu]

there's still a problem when using your commit codes, when input chinese, you can forcus the cursor to a gap between two words, is easy when using mouse, not left or right buttun。then "[" will be included in submitted input

Thanks for testing this.
I’m not sure I fully understand the exact reproduction steps yet.
Could you provide a more detailed step-by-step reproduction example?
A short screen recording or before/after example would also help a lot.

看你的昵称应该是中国人，我就用中文来描述现象吧，这边因为信息安全原因没法发图片，我用文字描述一下步骤吧 1、在输入框输入“快捷键测试用例” 2、用鼠标将光标点击到“键”、“测”之间，此时光标会选中“键”的右半边，“测”的左半边 3、粘贴几行文字，在“键”、“测”之间就插入了“[Pasted ~10 lines” 4、回车提交 5、在会话框，看到显示的文字是 “快捷键[....测试用例” （其中...是粘贴的多行内容），可看到展示的内容多了个[

This issue is reproducible in opencode, but the root cause appears to be lower-level in @opentui/core rather than in opencode's prompt logic.
TextareaRenderable seems to allow the cursor to land on an invalid visual column inside a double-width character (for example CJK characters), instead of snapping to a valid character boundary. Once that happens, higher-level logic in opencode receives an invalid visualCursor.offset, which then causes downstream misalignment in insertText, extmark ranges, and placeholder replacement.
So while opencode can add local workarounds, the proper fix likely belongs in the opentui repository, specifically in TextareaRenderable cursor movement / mouse hit-testing for wide characters.

[getbug]

i was wondering when will your commits merge into dev??? it fixed the bug mostly