From b3ac8fc259f8c803155b33f5452a15f07e22d997 Mon Sep 17 00:00:00 2001 From: Stefan Haller Date: Mon, 22 Jun 2026 16:37:07 +0200 Subject: [PATCH] =?UTF-8?q?Session=20notes:=20correct=20the=20patch-explor?= =?UTF-8?q?er=20claim=20for=20the=20driver=20fix=20(=C2=A721.32)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The driver fix is a no-op for the old staging panel, not a tightening: that panel anchors its drag at the click on mouse-down, so it never exposed the bug. Co-Authored-By: Claude Opus 4.8 (1M context) --- focused-main-view-notes.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/focused-main-view-notes.md b/focused-main-view-notes.md index 3f0064abc..c139da41c 100644 --- a/focused-main-view-notes.md +++ b/focused-main-view-notes.md @@ -3461,5 +3461,13 @@ Follow-up bugs the testing surfaced, all fixed (no tests, prototype): first line of a drag showed the stale hunk-end anchor (range from block end → cursor) before re-anchoring. Symptom the user reported: "drag down one line → range from block end to here; one more line → snaps to anchored-at-click, correct thereafter." Fix: mark that first movement as a drag like every later one. No - `MouseRelease` consumers exist (only `MouseLeft`/`ModMotion`), and it also tightens the patch explorer's - drag (its selection now grows from the first dragged line, not the second). + `MouseRelease` consumers exist (only `MouseLeft`/`ModMotion`). + **Why the old staging panel (patch explorer) never showed this**, despite the same driver bug and its own + drag-select: its mouse-down anchors the range *at the click* (`HandleMouseDown` → `SelectNewLineForRange` → + `FocusSelection` → `view.SetRangeSelectStart(click)`), so the native anchor is correct from the start; the + skipped first-move event still drew a correct `[click, cursor]` range (it only delayed that panel's internal + `State` sync by one move, identical end state). The bug bites only when the anchor must *change* at + drag-start — the main view's case, where a click anchors at the hunk's far end. So the driver fix is + effectively a no-op for the patch explorer; it's needed only for the main view. (An earlier draft of this + note wrongly said it "tightens" the patch explorer's drag — it doesn't; the commit message never claimed + that.)