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
Issue: The @ file mention menu fails to trigger when preceded by Chinese (CJK) characters.
Observation: It requires extra spaces to trigger, following a specific mathematical pattern.
Mathematical Pattern: Required_Spaces = (Chinese_Character_Count) - 2.
Plugins
使用了oh-my-opencode
OpenCode version
opencode 1.14.48
Steps to reproduce
Examples:
3 Chinese chars: Works with 1 space.
5 Chinese chars: Fails with 1 space, works with 3 spaces.
10 Chinese chars: Fails with 1 space, works with 8 spaces.
Note:
Works perfectly with English text.
Suspect a mismatch in string offset calculation between UTF-8 bytes and character count (UTF-16/logical length) in the lookbehind logic.
Reproduction with shift+return (newline) as trigger — same offset calculation bug
I'm seeing the same "no results" behavior on @ autocomplete, but with a different trigger: newlines from shift+return.
Repro steps (macOS, v1.15.0, Ghostty terminal):
Open the TUI prompt
Type @ on line 1 → autocomplete works, file picker appears as expected
Press shift+return to insert a newline
On line 2 (or any line after a newline), type @ → autocomplete shows "no results"
The @ autocomplete works perfectly on the first line but breaks on every subsequent line after a shift+return newline. This is 100% reproducible — even a single newline before the @ is enough to trigger the failure.
Why this is the same root cause:
Issue #3734 (closed) identified the offset mismatch: visualCursor.offset counts differently than props.value.at. The reporter noted specifically that \n advances the cursor by 1 but Bun.stringWidth returns 0. The v1.14.49 fix for wide characters addressed the CJK case but did not fix the newline case.
My tui.json uses the current keybinds format (not the deprecated keymap), so this isn't a config issue. The offset calculation for the @ trigger position is simply wrong when any \n precedes it in the input buffer.
Activity
github-actions commentedon May 13, 2026
This issue might be a duplicate of existing issues. Please check:
@mention autocomplete fails when preceded by Chinese (CJK) characters, same version (1.14.48)If this is the same issue, consider adding your additional details (the offset calculation pattern) as a comment on #27290 instead.
unomaas commentedon May 15, 2026
Bumping this for visibility, +1.
Reproduction with
shift+return(newline) as trigger — same offset calculation bugI'm seeing the same "no results" behavior on
@autocomplete, but with a different trigger: newlines fromshift+return.Repro steps (macOS, v1.15.0, Ghostty terminal):
@on line 1 → autocomplete works, file picker appears as expectedshift+returnto insert a newline@→ autocomplete shows "no results"The
@autocomplete works perfectly on the first line but breaks on every subsequent line after ashift+returnnewline. This is 100% reproducible — even a single newline before the@is enough to trigger the failure.Why this is the same root cause:
Issue #3734 (closed) identified the offset mismatch:
visualCursor.offsetcounts differently thanprops.value.at. The reporter noted specifically that\nadvances the cursor by 1 butBun.stringWidthreturns 0. The v1.14.49 fix for wide characters addressed the CJK case but did not fix the newline case.My
tui.jsonuses the currentkeybindsformat (not the deprecatedkeymap), so this isn't a config issue. The offset calculation for the@trigger position is simply wrong when any\nprecedes it in the input buffer.github-actions commentedon Jul 15, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.