| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new line, the line itself
In a diff pane (a .diff/.patch file, or a command pane's diff output), the
look's own expansion, which its hover shows, takes a whole line for a
`diff --git`, `---`, `+++` or `@@` line wherever the pointer is on it,
markers included, and for a hunk line when the pointer is on its `+`, `-`
or space. Then the look opens the file (a/ b/ dropped, timestamps cut) at
the line from the hunk header and the lines above it: `@@` the hunk's
first new line, context and added lines their own, a removed line the new
line now where it was. `diff --git` and `+++` open the new file; `---` the
old one, unless the `+++` under it names another. On a hunk line's code
the expansion is its words, the prefix never one of them, and looks as
ever. Other panes are untouched.
Paths resolve in the repository (walking up to `.git` or `.jj` from the
diff's directory, or a command pane's), then that directory. A file not
here opens nothing and says `Look: b/x: no such file here`, or `deleted by
this diff`. A 9P look writing a whole line of the diff does the same.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
|
|
and removed rows tinted
A .diff or .patch pane, and a command pane whose output is a diff (`git
diff`, `git show`, `diff -u`; told by a `diff --git` line, or `---`/`+++`
with a `@@` under them, in its first rows), colour each hunk's code in the
language of the file its section names (`+++ b/<path>`, `--- a/<path>` for
a deleted file), with tree-sitter, as highlightLocations does for results.
src/diff.zig walks a unified diff by its `@@` counts, so a removed line
that reads `--- x` is no header. Each side of a hunk is parsed as one text
(context and removed lines the old side, context and added lines the new),
so a string or comment across lines colours as it does in the file; a side
no line takes its colours from is not parsed. A section's hunks share a
parse, in pieces of about 40 lines (a hunk past 80 is cut), only those in
view, and each piece's colours are kept by its bytes, so scrolling back and
a terminal's every repaint parse nothing again.
Added and removed lines carry a flag in their style byte; the painter tints
their rows to the pane's edge, a little way from the page toward the
theme's ANSI green or red, and draws the prefix in that hue pushed to read
on it. A file in no known language keeps the old line colours.
A command pane is read once its command has finished: its rows are copied
once (File.DiffOutput, dropped when the pane runs again), so no frame dumps
the scrollback, and painted over what git printed. A running command is
shown as it prints.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
