What
Verify whether silvery positions the hardware cursor at the composer's logical insertion point, and fix (or file upstream) if it doesn't. IME candidate windows (Chinese/Japanese/Korean input) anchor to the hardware cursor — if it's parked at 0,0 or hidden without repositioning, IME users get their candidate popup in the wrong place or nowhere useful, making the TUI effectively broken for East Asian text entry.
Why we think there's a gap
Nothing in cli/silvery/ or the surviving cli/tui-*.ts modules addresses IME or hardware-cursor placement at all. Meanwhile we do already carry CJK width tables (cli/tui-renderer.ts charWidth: combining marks = 0, CJK/fullwidth blocks = 2), so wide-char users are clearly in scope for the product — rendering their text but breaking their input method would be an inconsistent story.
Design reference: pi-tui (earendil-works/pi, packages/tui) treats this as a first-class concern — its Focusable interface lets the focused component mark its logical cursor position with a zero-width CURSOR_MARKER escape sequence, and the framework moves the hardware cursor there each frame (hidden by default, but positioned so IME candidate windows land correctly).
Plan
- Verify with a real IME (macOS Pinyin/Hiragana, or
fcitx/ibus on Linux) against the composer (TextArea in cli/silvery/surface.tsx): does the candidate window track the caret?
- Inspect silvery 0.21.1 (
node_modules/silvery/dist) for any cursor-positioning support on TextArea/TextInput — it may exist and just need enabling.
- If missing: upstream feature request to silvery (a
CURSOR_MARKER-style contract is the proven shape), or a small shim that emits a CUP to the caret's screen cell after each frame — behind the existing render path, not a fork.
Acceptance
- IME candidate window appears adjacent to the caret in the composer and in modal text inputs (
InteractionModal, ConfigEditorModal).
- No regression for non-IME input; cursor visibility behavior unchanged for ASCII users.
- Finding documented either way (if silvery already handles it, note where, close as verified).
Related: #1530 (silvery feature-adoption track — this is a verification/gap item, not an adoption item, so tracked separately).
What
Verify whether silvery positions the hardware cursor at the composer's logical insertion point, and fix (or file upstream) if it doesn't. IME candidate windows (Chinese/Japanese/Korean input) anchor to the hardware cursor — if it's parked at 0,0 or hidden without repositioning, IME users get their candidate popup in the wrong place or nowhere useful, making the TUI effectively broken for East Asian text entry.
Why we think there's a gap
Nothing in
cli/silvery/or the survivingcli/tui-*.tsmodules addresses IME or hardware-cursor placement at all. Meanwhile we do already carry CJK width tables (cli/tui-renderer.tscharWidth: combining marks = 0, CJK/fullwidth blocks = 2), so wide-char users are clearly in scope for the product — rendering their text but breaking their input method would be an inconsistent story.Design reference: pi-tui (
earendil-works/pi,packages/tui) treats this as a first-class concern — itsFocusableinterface lets the focused component mark its logical cursor position with a zero-widthCURSOR_MARKERescape sequence, and the framework moves the hardware cursor there each frame (hidden by default, but positioned so IME candidate windows land correctly).Plan
fcitx/ibuson Linux) against the composer (TextAreaincli/silvery/surface.tsx): does the candidate window track the caret?node_modules/silvery/dist) for any cursor-positioning support onTextArea/TextInput— it may exist and just need enabling.CURSOR_MARKER-style contract is the proven shape), or a small shim that emits aCUPto the caret's screen cell after each frame — behind the existing render path, not a fork.Acceptance
InteractionModal,ConfigEditorModal).Related: #1530 (silvery feature-adoption track — this is a verification/gap item, not an adoption item, so tracked separately).