[Bug] Vertical editor navigation loses the visual column after wide Unicode characters

[Lauritz-Timm]

Affected area

Terminal UI prompt editor

What happened?

Moving the cursor vertically between prompt lines does not preserve the terminal column when the source line contains a wide Unicode character.

For example, a cursor immediately after the CJK character 你 is displayed at visual column 2. Pressing Down to move to an ASCII line places it at string offset 1 instead of visual column 2. Subsequent input is inserted one terminal column too far to the left.

Steps to reproduce

On a source checkout, run:

cd packages/tui
npx tsx -e 'import { Editor } from "./src/components/editor.ts"; import { defaultEditorTheme } from "./test/test-themes.ts"; import type { TUI } from "./src/tui.ts"; const editor = new Editor({ requestRender() {} } as TUI, defaultEditorTheme); editor.setText("你a\nabcd"); editor.handleInput("\x1b[H"); editor.handleInput("\x1b[A"); editor.handleInput("\x1b[C"); console.log("before Down", editor.getCursor()); editor.handleInput("\x1b[B"); console.log("after Down", editor.getCursor()); editor.handleInput("X"); console.log(JSON.stringify(editor.getText()));'

Current output:

before Down { line: 0, col: 1 }
after Down { line: 1, col: 1 }
"你a\naXbcd"

The cursor is visually two columns from the start before Down, so inserting X after moving to the second line should place it after b, not after a.

Expected behavior

Vertical Up and Down movement should preserve the displayed terminal column across lines. In this example, Down should move to column 2 of abcd, and the resulting text after inserting X should be "你a\nabXcd".

Prime Agent version

Current main at 97b994c3d7c45ca1ae635190e91e9e58ddf2577c

Environment

Fedora Linux x86_64, Node.js v22.23.1

Additional context

The editor stores cursor positions and visual-line segment boundaries as UTF-16 string offsets. moveToVisualLine() derives its preferred “visual” column by subtracting those offsets, so a width-2 grapheme is counted as one column. Combining graphemes can produce the inverse mismatch.

I can add a focused editor regression and a narrow fix if maintainers want this behavior changed and invite the implementation.