From 0f99ba625a694fcff15de6a0219714de8658a815 Mon Sep 17 00:00:00 2001 From: Stefan Haller Date: Sat, 20 Jun 2026 21:06:05 +0200 Subject: [PATCH] =?UTF-8?q?Session=20notes:=20first-drag-event=20driver=20?= =?UTF-8?q?fix=20(=C2=A721.32)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- focused-main-view-notes.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/focused-main-view-notes.md b/focused-main-view-notes.md index 24a22b6e5..3f0064abc 100644 --- a/focused-main-view-notes.md +++ b/focused-main-view-notes.md @@ -3454,3 +3454,12 @@ Follow-up bugs the testing surfaced, all fixed (no tests, prototype): between mouse-down and its drag, so no patch-identity needed). The old (buggy) behaviour came for free from `selectDiffHunk` leaving a range anchor + gocui moving the cursor on drag; nothing handled the drag explicitly before. + **Follow-on (`e74a33880`), a gocui driver bug the above exposed:** the *first* drag-movement event was + reported as `MouseRelease`, not `MouseLeft`+`ModMotion` — the tcell driver's `MAYBE_DRAGGING → DRAGGING` + transition (`tcell_driver.go`) set the state but left `mouseKey`/`mouseMod` at their defaults. gocui still + moved the cursor for it, but `onDragInFocusedView` didn't fire until the *second* moved-to line, so the + 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).