Summary #
The fix for double-counted vis_col uses a local accumulator sc, but the virtual text segment handling still adds vis_col to seg.col.
The Problem #
In src/cursed/view/view_token.lua lines 326-348, the TEXT segments now use a local accumulator sc for within-segment column tracking, which is correct. However, the virtual text segment branch (lines 306-321) still does sub_cols[gi] = seg.col + total_vt_w and updates vis_col = vis_col + total_vt_w. The virtual text segments may also span multiple buffer graphemes, but they map ALL graphemes in the span to the same sub_cols (start or end). This could cause a double-count if the virtual text span overlaps with a TEXT segment on the same row. But the tokenizer ensures virtual text and buffer text are separate segments. The issue might be subtle: virtual text segments contribute to vis_col for the row width, but the mapping assigns all graphemes to seg.col or seg.col + total_vt_w, not accounting for intermediate buffer graphemes within the span. This could cause sub_cols for graphemes inside the span to be wrong if the span covers multiple graphemes. However, virtual text replaces buffer bytes, so those buffer graphemes are not displayed; the mapping is for mouse hits and cursor positioning inside the replacement text. The fix for TEXT segments uses sc, but virtual text remains as before. Could be a separate issue.
Impact #
- category: correctness
- description: double-counted sub_cols for virtual text spans in wrap_graph_cache may cause incorrect cursor/mouse coordinate mapping
Recommended Fix #
If virtual text spans replace buffer graphemes, consider using a similar local accumulator for the virtual text visual footprint instead of accumulating vis_col with total_vt_w per span. The current code may double-count if multiple virtual text spans are on the same row.
Commit range: ce365b1..ce365b1
Code Review: CR-2026-07-27-11