fix: single-line files — decorate the visible wrapped rows, and stop the wheel snapping to a 100 KB boundary

[sinelaw]

Fixes both defects in #2843, on top of #2841. Two independent fixes, one commit each.

1. Highlighting turns uniform after the first few wrapped rows

The decoration pass asks for a byte window built from top_byte and calculate_viewport_end, which walks logical lines from top_byte and clamps each to one screen row's worth of columns. Correct for horizontal scrolling — and it is what bounds the per-frame scan behind #2529 — but under soft wrap neither half holds: the drawn rows can all belong to one logical line, and the top row can sit thousands of wrap segments into it.

Instrumenting the call confirms it: on the issue's fp4_poll.json the request stays at 0..952 no matter how far down you scroll. Whatever single span overlapped that window was returned in full and painted every row below it; once nothing overlapped, the rows were left bare.

Under wrap, the window is now derived from the view lines about to be rendered — they already carry a source byte per character, so the span is exact and costs a walk proportional to the screen, not to the line. The unwrapped path keeps calculate_viewport_end unchanged. The overlay, bracket and diagnostic passes take the same window and get the same correction.

Note on the issue's leading hypothesis — it does not hold up, and no fix was needed there. Feeding the whole 441 KB line to ParseState::parse_line in one call keeps the scope stack at string.quoted.double.json at byte 43,059, 50,000 and 200,000; TextMateEngine::highlight_viewport returns String@49994..50005 for the 50,000..54,000 window. syntect never leaves the string state, so parse_line_into_spans is not at fault and nothing needed chunking or state carry-over. The reported Comment@43059..62192 was a rendered symptom of the window bug above: one span overlapping 0..952 gets returned whole and colours everything below it.

2. Wheel scroll collapses to a chunk boundary

MAX_LINE_BYTES (100,000) is the budget LineIterator uses to avoid materialising a huge line at once — it splits such a line into pieces and yields each as a separate "line". That is a read budget, not document structure, but the wrapped-scroll math consumed it as a line boundary: it counted the visual rows of a 100 KB piece, ran out of rows inside it, and "advanced" to the next piece as if it were the next line. The scrollbar reads VisualRowIndex (real logical lines) and disagreed — hence the jump on the first notch after a scrollbar jump.

LineIterator::next_logical_line rejoins the pieces up to the real terminator; every wrapped-scroll path now reads through it (scroll up/down, the scroll limit, the max-scroll search, the clamp, cursor-row math). next_line keeps its budget for callers that stream.

The per-line row-count cache made this stick even after the traversal was fixed. It is keyed by line_start, so the piece-based caller had stored 916 rows under the key for a line that is really 4130 rows, and every later lookup — wheel, scrollbar clamp, ensure-visible — read that back. The cache is now gated on the text actually covering the line, so a partial-line caller (the cursor-row prefix math passes one too) cannot poison it.

Measured on the issue's file, 120×30:

	before	after
scrollbar click	top_byte=0 offset=1642	top_byte=0 offset=1642
wheel ×1	top_byte=100000 offset=3	top_byte=0 offset=1645
wheel ×6	top_byte=100000 offset=18	top_byte=0 offset=1660

Tests

tests/e2e/issue_2843_single_line_viewport.rs — two e2e tests, both driving mouse only and asserting on rendered output:

• wheel_after_scrollbar_jump_continues_from_the_jump_position reads the topmost ascending marker off the screen before and after one wheel notch.
• wrapped_long_line_keeps_syntax_colours_when_scrolled_into jumps two thirds down the track into a line of ascending "M######":424242 pairs and asserts the visible key and value still render in different colours. The marker read off the screen doubles as the precondition, so a jump that left the view at the top of the line (where highlighting worked even before the fix) fails loudly instead of passing vacuously.

line_iterator.rs — two unit tests for next_logical_line (spans chunk boundaries and lands on the next line's start; unterminated tail). Not screen-visible, so unit-level per CONTRIBUTING §2.

Verification

cargo fmt, cargo clippy --all-targets (no new warnings in the touched files) and cargo check --all-targets are clean; the full lib suite passes (3134 tests). Both e2e tests pass locally, and the highlighting one was verified failing with the decoration-window fix reverted (key and value both render undecorated white) and passing with it.

Both bugs were also reproduced, and both fixes confirmed, against the real fp4_poll.json through the editor harness before any test was written.

An adjacent defect this branch does not fix

The first revision of the highlighting test jumped to the bottom of the scrollbar track, and the tail never appeared. Cause: at max scroll the scrollbar's VisualRowIndex counts more wrap rows than the renderer builds — they derive the gutter width differently — so the requested row offset lands past the last view line and render_buffer silently falls back to the top of the line. Reproducible on master, same area as #1574 / #2649, and out of scope here; the test now lands where the two agree. Worth a separate issue.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F54wthCxJtDmeUmgmnZzoU