Skip to content

[Bug] @ mention trigger fails after CJK characters (offset calculation error) #27293

Closed as not planned

Description

@nanfxqs

Description

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.

Screenshot and/or share link

Image

Operating System

WSL- Ubuntu 24.04.3 LTS

Terminal

Windows 环境下的 WSL2 Ubuntu 子系统 Bash 终端

Activity

  1. github-actions commented on May 13, 2026

    @github-actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    If this is the same issue, consider adding your additional details (the offset calculation pattern) as a comment on #27290 instead.

  2. unomaas commented on May 15, 2026

    @unomaas

    Bumping this for visibility, +1.


    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):

    1. Open the TUI prompt
    2. Type @ on line 1 → autocomplete works, file picker appears as expected
    3. Press shift+return to insert a newline
    4. 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.

  3. github-actions commented on Jul 15, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions