GrDiff

A ready merge view would give less code on our side and a mandatory CodeMirror for whoever came simply to look at what changed. Of the three scenarios of the package, reading a diff is the most frequent: the log is opened by everyone, and the config is edited by one administrator in a hundred. There is no point making reading pay for the editor.

The second argument is the styling: someone else’s merge view has a palette and classes of its own, and our tokens get in there by overriding foreign selectors and hold until the next minor of the library.

The complexity of Myers’s algorithm depends on the edit distance rather than on the length of the input. Two files of ten thousand lines each, differing entirely, are a frozen tab, and it is the user who will see it rather than the developer.

Beyond the limit (budget) the parsing goes into a coarse pass: the common prefix and suffix remain, and the middle is counted as replaced entirely. The diff stays correct — simply less detailed — and reports that with a budgetExceeded emit and a line in the summary. That is better than a frozen tab and more honest than silence.

Inside a changed line the changed word is marked. Without that an edit of one word reads as “the whole line is different”, and the diff stops answering its own question.

A line with no spaces — a long base64, a minified JSON — is exempted from the word-level parsing: it degenerates into a character-level one, highlights every other sign and costs a lot. Such a line is shown more honestly as changed in full.

The pair for the parsing is taken from the block of the edit as a whole rather than from the neighbouring rows. diffLines outputs a block with the deletions first and the additions after (-a -b -c +A +B +C), and counting by neighbours would bring together -c and +A — lines that have nothing to do with each other. The k-th deletion stands against the k-th addition; a block of unequal length is padded with an empty side.

A diff of a config of a thousand lines with one edit is obliged to open showing that edit. context lines are left around every change, and the rest is folded into an expandable gap.

context: 0 leaves the changes alone, and Infinity folds nothing.

A gap is expanded in steps from either edge, as in a code review: the piece you need is looked for next to the edit rather than by unfolding the whole file. The strip of the gap carries two buttons — ”↓ N” opens N lines at the start of the gap, ”↑ N” at the end — and a counter between them. The size of the step is set by expandStep (10 by default) and, like context, is configured for the application through GrConfigProvider.

A remainder smaller than the step is opened in full, and the strip turns into a single button: a button that will open nothing more is a dead end people run into exactly once and then stop believing it.

Expanding from the top holds the gap in place: the lines stand above it, and without a correction for their height the content moves down by exactly as much — the user pressed “show more” and lost sight of the very edit they were looking at. The increment is taken by measurement rather than by computing “lines × height”: the height of a line depends on the type size and on wrapping.

Expanding one gap does not touch its neighbours: their identifier is the position of the first line of the section rather than of the first hidden one and not an ordinal number. Count it by the hidden ones and it would change at every step, and the state would lose its own gap: a second press would open it again from scratch.

The summary is declared a live region: without it a screen reader reads a stream of lines without understanding that a comparison is in front of it.

Colour is not the only carrier of meaning — otherwise that is WCAG 1.4.1. What was added and what was removed are told apart by a sign in the gutter (+ / −): a diff is read on monochrome printouts as well. The sign stands in both modes: in split it is in every column of its own rather than only in unified.

The comparison area is a scroller and is therefore reachable from the keyboard.

A long diff is cut by a rendering window, and useVirtualList gives away only the heights of the spacers as variables — the pseudo-elements themselves are declared by the component, in its own <style>. Without that rule there is nobody to read the variables: the container stays one window tall, there is no scrolling at all, and out of a thousand lines the first dozen are reachable. The markup is valid in the process, and the failure is visible only to the eye — which is why the rule is held by the virtualSpacer.test.ts gate.

The row is given away by the slot as a whole — for a “copy the line” button, a link to a discussion, the mark of a reviewer. The slot receives line and works in both modes; in split the line of the right side arrives, and for a lone deletion the line of the left one.

It does not edit. It does not resolve conflicts. It does not parse a unified diff from git: hunks are accepted as a typed structure of their own, because a parser of a unified diff has edges (\ No newline at end of file, the arithmetic of the header, binary files), and a parser that is wrong at an edge is worse than a missing one — it does not fail, it shows a wrong comparison.