struct VisualLayout

Creates a layout from row ranges. An empty list becomes a single empty row, so there is always a row for the caret.

How many visual rows there are.

Character range of each visual row over the whole buffer, in order.

The caret's column within its row: characters from the row's start to offset. affinity picks the row at a wrap boundary, as for rowIndex(ofOffset:affinity:).

The same scan, also reporting where each line sits in bytes.

Character offsets are what the row table is stated in. Byte offsets are what a cheap comparison of two buffers produces, and what slicing one line out of the buffer wants — and a wrapping editor needs both on every edit, so it asks for them together rather than scanning twice. Everything else asks for logicalRows and does not pay for the second array, which on a 200,000-line log is not a rounding error.

One row per logical line — the no-wrapping case.

Row boundaries for logical(_:), exposed separately so a caller (an editor leaf with wrapping off) can cache the result via TextEditingState.setVisualRows instead of recomputing this O(length) scan on every layout access — which, left uncached, is what a large buffer felt: every caret draw, hit test, and gutter row rescanned the whole document.

Offset at row/column, clamped to that row.

Row containing offset.

At a soft-wrap boundary one offset is both the end of a row and the start of the next, and there is no way to pick from the offset alone — which is why carets carry an affinity. Upstream keeps the caret on the row that ended (where a clamped vertical move should stay); downstream puts it on the row that starts (where a click or Home should land).