Include settings for disabled features, paint additional styles and decorations, and preserve hunk-header attributes.
Run tests from the repository root:
cargo test subcommands::show_config::tests
cargo test
Checks: cargo fmt --all --check; cargo clippy -- -D warnings
DELTA_FEATURES=+keep-plus-minus-markers now keeps the markers without a
[delta "keep-plus-minus-markers"] section in git config, as a host such as
gitu needs to offer it. raw sets the option, so, as side-by-side does with
line-numbers, it now brings the feature in by name; the feature lists the
tests expect say so.
cargo test features::tests
mdbook 0.5 rejects book.toml's multilingual field and the fa-github icon name;
both were defaults anyway. Close three table cells, and escape '<=' and
'<SHELL>', which mdbook 0.5 parses as HTML.
cd manual && mdbook build
* Include the mode change in the width of file header decorations
If the mode of a file changes, delta adds the change to the file header,
as in "src/delta.rs (mode +x)". With file-decoration-style "box", the top
and bottom edges of the box cover only "src/delta.rs ", so they are too
short for the text. With --width=variable, the underline is too short in
the same way.
This happens because the draw functions measure the text before they add
the mode change to it.
Measure the text that the draw functions write instead. Add
text_to_write() for this. It returns the raw text, or the painted text
with the mode change, and all draw functions now use it.
The box still has two spaces before "(mode +x)". This comes from the
space that callers add to the text for boxes, and this commit doesn't
change it.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
* Keep decorations within the width given by --width
If a file path or a hunk header is wider than the terminal, its
decoration is drawn wider than the terminal too. The terminal then wraps
the lines of the decoration, and the header becomes hard to read
(#2043). This happens often in narrow terminals, and in lazygit, where
the diff gets only part of the screen.
The decorations grow with the text. An underline or overline is as wide
as --width, or as wide as the text if the text is wider. A box is always
as wide as the text. If --width isn't set, delta uses the terminal width.
Draw underlines and overlines exactly as wide as --width. Delta doesn't
wrap their text; the terminal still does this. If the text of a box is
too wide, wrap it inside the box so that the box is as wide as --width.
Lines break at any character, like they do in the terminal, and each
line keeps a space before the right edge of the box. Add ansi::wrap_str()
for the wrapping. If a style or a hyperlink is active where a line ends,
wrap_str() ends it there and starts it again on the next line.
With --width=variable, decorations still extend to the end of the text,
as the help text for --width says.
Three tests used text that is wider than the test width of 43 columns,
and they expected the decorations to grow with it. Give them a --width
that fits the text, so they still test the case they were written for.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
* Explain why wrap_str does not reuse wrapping::wrap_line
* Merge text_to_write into paint_text, its only caller
* Fix submodule metadata snapshot: underlines no longer exceed --width
Run tests with: env -u OSC1717 cargo test
---------
Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>
Co-authored-by: Dan Davison <[email protected]>
Emit custom OSC1717 C record on all commit header rows.
This is intended to help TUIs navigate by commit and attach keybindings to commits.
C is not in the spec, which defines c/a/d/f/h.
Hosts must ignore unrecognized types, so this should not break hosts.
* Emit per-line diff metadata as an OSC sequence for host applications
A host that renders delta's output (e.g. lazygit) needs to map a
rendered diff row back to its patch-space identity -- file, line type,
and new/old line numbers -- to act on the line the user points at.
delta's default rendering drops the +/- markers and conveys the side by
color, so that identity cannot be recovered from the painted text; the
pager, which still has it at render time, has to state it.
Gate the emission on the OSC1717 environment variable so output is
byte-for-byte unchanged outside such a host -- harmless in a raw
terminal, less, or tmux. The host advertises the protocol versions it
understands and delta emits the highest mutually-understood one
(currently always v1 because that's the only version that exists, but
the mechanism is extensible).
The metadata rides on a dedicated, purely-additive emitter rather than
reusing LineNumbersData: delta only maintains its line-number counters
when --line-numbers is enabled, and forcing that on would also render a
gutter and change wrap-width math. The emitter tracks its own counters
(seeded from the hunk header, mirroring
LineNumbersData::initialize_hunk) and only injects OSC bytes, leaving
all styling and layout untouched.
This commmit covers the normal unified single-column path only;
side-by-side mode is going to be supported in the next commit.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Emit per-line diff metadata in side-by-side mode
The unified emitter funnels every content line through
Painter::paint_lines, but side-by-side renders each visual row as two
panel halves painted directly via Painter::paint_line, so the unified
emit point never fired for it. Attach the OSC per cell instead: the left
panel's cell carries the minus line's identity, the right panel's the
plus line's, and a context line -- shown in both panels -- carries the
same record before each half.
The line-number counters in side-by-side are advanced per aligned row
(with increment flags and post-hoc fixups), not in the unified "all
minus, then all plus" order that osc_for_line's arithmetic assumes. So
rather than call osc_for_line inline at each panel paint, precompute the
per-line OSC strings for the whole minus block and then the whole plus
block -- the unified order -- and look them up by the same index that
selects each line's state. The emitted records stay byte-identical to
the single-column emitter, and the shared counters still land where the
next hunk block expects them.
Side-by-side is also the only mode that wraps a long line, into several
output rows with Hunk*Wrapped states. delta emits each wrapped row as a
distinct output line, so a host sees them as distinct lines and needs
the identity on each -- otherwise acting on a continuation row, or
treating the wrapped line as one block when navigating, breaks. Each
wrapped row therefore re-emits the record of the primary line it
continues, without advancing the counters (so the next line's numbers
stay correct); empty counterpart cells still get no OSC.
Context lines were previously not routed through the emitter at all in
side-by-side (paint_zero_lines_side_by_side never saw it), which would
have desynced the counters; thread it through there too.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Emit a version-only metadata handshake as the first output
A host can already learn delta's per-line diff metadata, but only from
the records emitted before content lines — so a diff with no content (a
binary file, or the empty diff a host would use to probe) emits nothing,
and "speaks the protocol" is indistinguishable from "unsupported pager".
Emit a version-only OSC 1717 record (no further fields) once, before
consuming the diff, whenever a version is negotiated. It's
content-independent, so a host can probe delta on an empty diff and get
a conclusive answer.
See the diff-line-metadata OSC spec, §4.4.
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
* Emit `f` and `h` records on file and hunk header rows
Annotate the structural rows too: every row of a file-header block
carries an `f` record, and every row of a hunk-header block an `h`
record (spec §5.1/§6.4). This lets a host anchor file and hunk
navigation on the headers themselves, act on a header row, and see
files that emit no content records at all (pure renames, mode-only
changes, binaries).
The two types deliberately differ in payload (spec §5.5): `h` always
carries the hunk's first new-file line, which is in hand exactly when
the header is drawn (initialize_hunk has just seeded it), while `f`
never carries one -- delta draws the file header when it parses the
`+++` line, before it has seen the first `@@`, so a line number there
would require buffering the whole header. The emitter does not know
the path at that point either, so diff_header_osc supplies it, with
the same plus/minus selection the hunk header uses.
Both headers are multi-row decorations written row by row by the draw
functions, so write_with_header_osc wraps the writer in a line-aware
prefixer that repeats the record at the start of every row of the
block -- the same rule wrapped content rows follow (spec §6.3). The
grep code shares the hunk-header draw helper and passes no record.
With OSC1717 unset, output remains byte-for-byte identical to stock
delta.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
* Take the terminal width from $COLUMNS when it is set
Delta learns how wide to render by asking the terminal on its stdout. A caller
that runs delta with no terminal there cannot state a width, so delta falls back
to 80 columns. Editors and TUIs that render delta's output into one of their own
views hit this, and have to pass --width on every invocation.
Read $COLUMNS first, and ask the terminal only if $COLUMNS is unset or does not
hold a positive number. Git resolves the width the same way in term_columns(),
and sets $COLUMNS for the pager it spawns, because its own stdout is a pipe to
that pager by then and the ioctl no longer reaches a terminal. Following git
keeps delta and the git process feeding it on the same width. An explicit
--width still wins over both.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
* Edit help text
---------
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
Co-authored-by: Dan Davison <[email protected]>
* Don't misparse git grep -h output as path=code
git grep's heuristic line parser tries several regexes to infer a
path+separator+code structure, since grep/rg output format is
inherently ambiguous. But -h/--no-filename suppresses the path
entirely, so every line is raw file content with no path/separator
structure -- a line like "foo=equals" (literal content) was being
misdetected as a path=code grep line purely by coincidence, stripping
the leading "foo=" from the displayed output.
Detect -h/--no-filename via the existing CallingProcess::GitGrep
option tracking (same pattern already used for -W and -p) and skip
heuristic parsing entirely in that case, since there's no reliable
filename signal to parse against.
Fixes#2192
Unrelated to this PR's actual fix (src/handlers/grep.rs) - these lints
newly fired because CI runs on latest stable clippy (1.97), which added
stricter defaults main hasn't hit yet since its last green run predates
this. All 5 are clippy's own suggested one-line fixes, no behavior change:
- side_by_side.rs: drop redundant .into_iter() on an IntoIterator param
- diff_header.rs: truncate(0) -> clear()
- merge_conflict.rs: drop redundant & in a writeln! arg
- set.rs, wrapping.rs: drop redundant & in format! args
The arm64/armhf .debs have empty Depends fields since
dpkg-shlibdeps doesn't resolve cross-compiled libraries.
Skip the libc version check for those instead of failing.
Move verify-release checks into a standalone workflow that can be
triggered manually (workflow_dispatch) or called from the CD pipeline
(workflow_call). This allows re-running verification against any
release without a new tag push.
- Fix .deb packages being uninstallable on Debian 12 due to glibc 2.39 dependency
(caused by building on ubuntu-latest/24.04 instead of ubuntu-20.04).
- Pin GNU Linux builds to ubuntu-22.04 (glibc 2.35).
- Add post-release verification of asset completeness and Debian 12 compatibility. Create releases as drafts so release notes can be written before the notification email goes out.
* Fix CD: replace discontinued ubuntu-20.04 runners; update Actions
ubuntu-20.04 runners were removed from GitHub Actions, causing 4 of 7
CD build targets to time out waiting for a runner (issue #2127).
- Replace ubuntu-20.04 with ubuntu-latest in cd.yml
- Update actions/checkout v3 → v4 (Node.js 20 deprecation)
- Update softprops/action-gh-release v1 → v2
When hyperlinks are enabled but the absolute path cannot be resolved
(e.g., in --show-themes context), fall back to displaying the formatted
line number instead of incorrectly showing the filename.
Fixes#1887🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <[email protected]>
* demonstrate issue around missing line numbers
* default line number to 1 for hyperlinks
this fixes links to files that don't have a line number
fixes https://github.com/dandavison/delta/issues/1965
With `interactive.diffFilter = delta --color-only` delta is called
by e.g. `git add -p`, but in this mode git hides the terminal from
the pager.
Plus/minus lines correctly use ANSI sequences to paint up to to the
end of the line, but zero lines always use spaces. This needs the terminal
width, but it is not available for diffFilter. So the fallback
of 80 is used, and zero styles did not extend to the full terminal width.
Since zero lines are only rarely styled (e.g. via
`--zero-style='syntax "#1d1f21" dim'`), this was never noticed.
This also crashed delta when a zero line was longer than 80.
Output can be generated directly via Painter::write, or Painter::output_buffer.
The latter must be emit()'ed before the former method can be used again,
otherwise the order is incorrect.
Tests added. Fixes#1504
Justin Su