From ec1bdaafb3bc4fa5c70f46e9421d9489260ac483 Mon Sep 17 00:00:00 2001 From: Stefan Haller Date: Thu, 18 Jun 2026 12:35:47 +0200 Subject: [PATCH] Session notes: record session-13 interactive feedback on step 3 Co-Authored-By: Claude Opus 4.8 (1M context) --- focused-main-view-notes.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/focused-main-view-notes.md b/focused-main-view-notes.md index 04d249010..9a6b43bcf 100644 --- a/focused-main-view-notes.md +++ b/focused-main-view-notes.md @@ -2352,3 +2352,16 @@ deletion + its replacement + context, exercising the resolution fix), - **Interactive sign-off pending** (per §21.9, single increments only become testable once this is in; the user evaluates the feel — e.g. hunk-default jump-on-focus, delta's background-conveyed side under the highlight per §21.9). + +**Interactive feedback, session 13 (user; both OK to leave for now):** + +- **delta + hunk selection makes the §21.9 colour problem worse.** With a whole hunk + selected you see one solid block of blue with no boundary between the deleted and added + lines — delta conveys add/delete purely by background, which the selection overrides. + Worse than the single-line case. Still deferred (same class as the §21.5 overlay — a + gutter marker / foreground treatment / reserved column is the eventual answer). +- **`a` on a context line below the last hunk diverges from the staging panel.** The + staging panel selects the *last* hunk (searches backward when there's nothing forward); + ours keeps the single line (`ChangeBlockBounds` only snaps *forward* to the first block + at/after the anchor, finds none, falls back to a single-line selection). Minor; to match, + `ChangeBlockBounds` would fall back to the nearest block *above* when none is at/below.