From 9db3094e805e3e984dad10c9e79fa061e9cb25ce Mon Sep 17 00:00:00 2001 From: Stefan Haller Date: Sat, 13 Jun 2026 22:47:17 +0200 Subject: [PATCH] Drop the synthesized-deletion limitation from the OSC spec MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Re-verified empirically: a pure deletion's new-line is exact at default context (difftastic emits d;4;4) and only drifts at --context 0 (d;1;4, low by the elided count); old-line is exact either way. lazygit renders at default context, so the drift isn't reachable in normal use, and even at zero context the only effect is that 'e' on a deleted line opens the new file a few lines off — inherently approximate, since the line isn't in the new file. Too marginal to keep as a v1 limitation, so §8 collapses to the single token-vs-line note. Re-verification recorded in the design notes. Co-Authored-By: Claude Opus 4.8 (1M context) --- diff-line-metadata-notes.md | 7 +++++++ diff-line-metadata-osc-spec.md | 20 +++++--------------- 2 files changed, 12 insertions(+), 15 deletions(-) diff --git a/diff-line-metadata-notes.md b/diff-line-metadata-notes.md index 66fb1119d..920b7dd9f 100644 --- a/diff-line-metadata-notes.md +++ b/diff-line-metadata-notes.md @@ -744,6 +744,13 @@ argument yet for the v2 "both numbers always". `num_context_lines = 0` (the previous new line is then far away). Documented, not a blocker — the deletion's *old*-line (its real identity for staging) is always exact; only the editor-target new-line is approximate. + - **Session 9: re-verified empirically and dropped from the published spec as too + marginal.** A single mid-file pure deletion emits `d;4;4` (exact) at default + context but `d;1;4` (new-line drifted low by the elided count) at `--context 0`; + `old-line` is exact in both. Since lazygit renders at default context, the drift + isn't reachable in normal use, and even at zero context the only effect is `e` on + a *deleted* line opening the new file a few lines off (inherently approximate). + So it's no longer a spec §8 item. - **Inline mode proves the metadata's worth beyond layout.** Inline groups **all old-side lines, then all new-side lines** (not interleaved like git). A modification's `d` (deletions group) and `a` (additions group) are therefore diff --git a/diff-line-metadata-osc-spec.md b/diff-line-metadata-osc-spec.md index cd0a3d42d..259a146e8 100644 --- a/diff-line-metadata-osc-spec.md +++ b/diff-line-metadata-osc-spec.md @@ -320,13 +320,12 @@ is designed for, to make the emit rules concrete. --- -## 8. Known limitations and v2 candidates — feedback wanted +## 8. A known limitation and v2 candidate — feedback wanted -None of these blocks v1; each is a place where input would shape a future version. +This doesn't block v1; it's a place where input would shape a future version. -### 8.1 The token-vs-line model mismatch (difftastic, AST mode) - -Our `c`/`a`/`d` set is git's **line-granular** shape: a modified line is a `-` plus +**The token-vs-line model mismatch (difftastic, AST mode).** Our `c`/`a`/`d` set +is git's **line-granular** shape: a modified line is a `-` plus a `+`. difftastic, when it parses the language (its **AST/token mode**), is finer — it aligns lines and marks novelty per token. A line changed *only by added tokens* (e.g. `println!("{}", x);` → `println!("{}", x + y);`) then has **no novelty on the @@ -343,15 +342,6 @@ users act on the changed side). A `modified`/`m` type — "aligned, changed, pre on both sides" — would name the case directly but splits the clean `c`/`a`/`d` mapping; recorded as a v2 candidate, not taken (§9). -### 8.2 Pure-deletion `new-line` in token tools is synthesized - -A line-granular pager always knows the new-file position a deletion sits at. A -token tool without a linear new-file counter (difftastic) computes it from the -previous aligned new line (`prev_rhs + 1`). This is exact for the common case but -can drift across hunk boundaries or with zero context lines. The deletion's -*old*-line (its real identity for staging) is always exact; only the editor-target -`new-line` is approximate. Pagers should emit the most precise `new-line` they can. - --- ## 9. Where feedback is most wanted @@ -363,7 +353,7 @@ can drift across hunk boundaries or with zero context lines. The deletion's central registry, so this is "verified unused across the terminals that matter," not "allocated." If you know of a terminal that interprets `1717`, please say so. 2. **The env-var name and grammar** (`EMIT_OSC1717_METADATA=V1,…`). -3. **The token-vs-line mismatch** (§8.1) — should there be an `m` type, or is +3. **The token-vs-line mismatch** (§8) — should there be an `m` type, or is host-side inference the right home for it? 4. **Can your pager actually produce all four fields per region?** In particular the side for deleted lines, and in side-by-side mode. (delta needed to track