mirror of
https://github.com/patriceckhart/zot.git
synced 2026-06-27 22:06:31 +02:00
797041288d
When the interactive editor's Prompt carried ANSI styling — the themed "▌ " glyph that interactive mode builds via cfg.Theme.AccentBar — the raw escape bytes leaked into wrapLine's per-rune width counter. Each byte of the SGR sequence (ESC, '[', digits, ';', 'm') reported runewidth 1, so an 11-byte color escape inflated the perceived prompt width by ~10 cells. wrapLine then made wrap decisions against that inflated width, locateCursor walked the inflated bodies, and Render() returned a cursor column that landed inside the wrapped row instead of at its visible end. The bug was intermittent because depending on the typed buffer's length the geometry sometimes aligned by accident. Drag-and-dropping a long screencaptureui temp path into VS Code's terminal reliably triggered it, since the path stays inline (the temp file is already gone by paste time so collapseOrQuoteFilePaths -> pathExists returns false -> falls through to verbatim insert). Fix: in Editor.Render, do all wrap and cursor math against a plain-text prompt (ANSI stripped via stripANSI), then re-attach the styled original to the very first wrapped row's leading substring before returning. Continuation rows already use an indent of spaces only, so they need no styling fixup. wrapLine itself stays ANSI-unaware on purpose: the rest of the codebase relies on its simple rune-based behaviour for plain text and making it ANSI-aware would be a much bigger change with regression risk elsewhere. Adds editor_ansi_prompt_test.go which reproduces the exact captured live scenario (the ANSI-themed prompt + the verbatim screencaptureui path + ' hello' typed afterwards) and asserts the cursor lands at the visible end of the last wrapped row. |
||
|---|---|---|
| .. | ||
| agent | ||
| assets | ||
| auth | ||
| core | ||
| extproto | ||
| provider | ||
| skills | ||
| tui | ||