struct TextEditingState

Which side of a wrap boundary the caret sits on. Only meaningful when the caret is exactly at one; see CaretAffinity.

Whether the buffer contains any hard line break.

Row structure currently in effect.

Logical lines, split on "\n". A trailing newline yields a final empty line, which is correct: the caret can sit there.

Collection.split compares Characters, so it grapheme-breaks the whole buffer to find bytes it could have scanned for — on a 4 MB log that is ~60 ms, and a wrapping editor asks for this on every keystroke. The scan below finds the newlines as bytes and cuts the same Substrings at them.

Which version of the content this is. Changes on every edit, and never for a caret or selection move.

Exists for the caches around this type. Converting between a String.Index and a character offset walks the buffer, so every consumer that does it in a hot path — the draw list's first visible row, the caret, a hit test — keeps the last pair it resolved and works relative to it. Such a pair is only meaningful for the buffer it was taken from, and "has the text changed" has no cheap answer otherwise: comparing two Strings is a content comparison, and comparing a copy of the state (this is a value type, copied constantly) says nothing about whether the text moved.

Process-wide unique rather than a per-instance counter, so a cache cannot mistake a freshly constructed state — whose counter would start over — for the one it sampled.

It participates in the synthesized Equatable, which makes equality stricter than it was: two states built separately from the same string are no longer ==. Nothing in the repo compares whole states (only their text), and leaving the conformance synthesized is worth more than the looser semantics — a hand-written == is one field away from silently ignoring the next thing added here.

Selection in document order, regardless of drag direction.

Edit history. Every mutation funnels through replace(...), which is what makes undo possible without auditing each operation separately — the thing the plan warned becomes painful to retrofit.

Visual rows, when the view has wrapped the buffer. Nil means one row per logical line. Vertical movement and Home/End follow these — with wrapping, a visual row is not a logical line, and navigating by newlines would skip whole wrapped rows.

Collapses to the caret end, as typing or a plain arrow key should.

Character offset of index within its own line.

Clamped with limitedBy: rather than against text.count, because String.count is a full grapheme-break walk of the buffer — O(length) regardless of how small offset is. The draw path calls this once per emit to reach the first visible row, so on a 10 MB log that single clamp cost ~12ms of every redraw, including ones that only moved a caret. limitedBy: costs O(min(offset, length)) and stops at the end.

Index at line/column, clamped to that line's length.

Zero-based logical line number of index.

Range of the line containing index, excluding its terminator.

Home/End act on the visual row, matching what the user sees. When nothing is wrapped this is the same as the logical line.

Moves up one line, preserving the column the user started from.

The remembered column is the whole point. Without it, stepping down through a short line and back up strands the caret at that short line's end instead of returning to the original column — the classic multi-line caret bug, and invisible until someone navigates ragged text.

Character offset of an index. Characters, not bytes, so the value stays meaningful across graphemes of differing byte length. Character offset of index, measured from the last pair resolved.

Both conversions here walk graphemes, so unaided they cost the offset, not the distance moved. Every vertical move makes one of each, so a caret near the end of a large file paid for the whole file to move one row — and Page Down, being a row move repeated a screenful of times, paid it thirty-odd times over. On a 4.7 MB buffer: 0.68ms per page at the top, 187ms twenty-seven thousand rows in, rising linearly and without bound. That is the reported symptom exactly — "the farther from the beginning, the laggier".

Anchored, the cost is the distance travelled: a row for an arrow key, a screenful for a page, and flat with depth. LeafNode already does this for the draw and drag paths; here it is where the caret itself lives, so every caller gets it rather than the two that remembered to.

Replaces a character range with replacement, as one undoable edit.

Offsets rather than String.Index because the callers are find/replace and an LSP-style edit, and both of those hold offsets from a scan that has already finished — see TextSearch.

Replaces every range in ranges with replacement and returns how many were applied. Ranges are character offsets over the current buffer, as TextSearch.matches reports them.

One undo step, not one per match. That is the whole reason this is here rather than in the caller: a replace-all is a single thing the user did, and undoing it a match at a time is the behaviour people file bugs about. It is done by rewriting the span from the first match to the last as a single edit, so the recorded removed text is that whole span — replacing across a large buffer holds a copy of it in the undo history until the history is dropped.

Overlapping ranges are not applied twice: after sorting, any range starting before the previous one ended is skipped. Empty ranges are skipped too — a zero-width match would otherwise insert replacement at every position between two real ones.

Selects the word containing index — what a double-click should do. Falls back to the run of separators when the click lands between words, so a double-click on whitespace still selects something coherent.

Replaces the whole buffer, e.g. when the bound value changed elsewhere.

Installed by the view after each wrap pass.

Start index of line n, or endIndex if n is past the last line.

The word-ish run around index, using the same classification as Ctrl+arrow so double-click and word movement agree.