Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg

[JDonaghy]

Continuation of #733, slice 6 of 6. #733 declared a 6-slice plan and was
closed when slice 1's PR merged — the remaining slices were never filed. This issue is
one of them. Measured on develop @ 44882e9 (2026-09-02):

handle_mouse (src/tui_main/mouse.rs) 3,044 · handle_mouse_event
(src/tui_main/shell_app.rs) 365 · handle_mouse_click_msg (src/gtk/mod.rs) 919 ·
handle_mouse_drag_msg 356 · try_route_sidebar_mouse_event 177 — 4,861 lines total,
against the 4,994 #733 was filed on. Slice 1 converged 133.

Locate everything below by symbol, not by line number — #733's own body warns that
its numbers drift, and they already have.

The closing slice

Slices 2a–5 move every rung into src/render.rs. This one deletes what is left and makes
the convergence permanent:

• handle_mouse (src/tui_main/mouse.rs) — gone, or a translate-and-delegate shim under
  ~150 lines.
• handle_mouse_click_msg, handle_mouse_drag_msg, try_route_sidebar_mouse_event
  (src/gtk/mod.rs) — same.
• handle_mouse_event (src/tui_main/shell_app.rs) — same.

Acceptance, in addition to the inherited block

• The five entry points total under 800 lines, from 4,861 at the time of filing. State
  the number.
• A test asserting both backends resolve the same ScreenLayout + point to the same
  route, verified RED by reordering one rung on one backend — the mouse twin of the
  FrameOp-sequence test Converge frame composition — ~4,500 lines laying down the same surfaces in two hand-kept orders #735 asks for. Without this, the ladder re-forks the first time
  someone adds a surface.
• No rung remains that one backend arbitrates and the other does not, or each surviving
  asymmetry carries a comment saying why it is genuinely one-sided (the folder picker is the
  known legitimate case — GTK uses a native chooser).

Acceptance criteria

Inherited verbatim from #733 — these are the rules that make a slice done:

• The rung is implemented once, in shared code (src/render.rs), and called from both
  backends.
• Both backends' bespoke arms for that rung are deleted in the same PR. A migration that
  leaves both paths is not done (GOALS.md, "How to use this doc").
• Black-box coverage on both backends — TuiDriver via driver_with_shell(TuiShellApp, …)
  in src/tui_main/shell_app.rs, and GtkDriver in src/gtk/testing.rs. Assert on rendered
  output, never on state being populated (CLAUDE.md rule 1).
• The PR states the new tests were verified RED against unfixed develop (CLAUDE.md rule 2).
• Combined production line count of the entry points above strictly decreases; the PR states
  before/after. (Converge the two mouse routers — ~4,800 lines implementing the same precedence ladder twice #733 slice 1 met this only barely — 4,994 → 4,861 — and Converge frame composition — ~4,500 lines laying down the same surfaces in two hand-kept orders #735 slice 1 did not
  meet it at all. State the numbers.)
• cargo build && cargo test && cargo clippy -- -D warnings && cargo fmt --check EXIT=0.

Scope discipline

This is one slice. Do not attempt the rungs belonging to the sibling issues listed in
Sequencing — they conflict in the same files and are queued behind this one on purpose.

Files

• src/render.rs (the shared router)
• src/tui_main/mouse.rs, src/tui_main/shell_app.rs
• src/gtk/mod.rs
• src/gtk/testing.rs (GtkDriver coverage)

Sequencing

Last of the #733 chain — after slices 2a, 2, 3, 4 and 5.

Milestone

#7 Platform-Neutral

[JDonaghy]

Coordinator Assignment

Machine: dell64
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

Issue #756: Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg

Continuation of #733, slice 6 of 6. #733 declared a 6-slice plan and was
closed when slice 1's PR merged — the remaining slices were never filed. This issue is
one of them. Measured on develop @ 44882e9 (2026-09-02):

handle_mouse (src/tui_main/mouse.rs) 3,044 · handle_mouse_event
(src/tui_main/shell_app.rs) 365 · handle_mouse_click_msg (src/gtk/mod.rs) 919 ·
handle_mouse_drag_msg 356 · try_route_sidebar_mouse_event 177 — 4,861 lines total,
against the 4,994 #733 was filed on. Slice 1 converged 133.

Locate everything below by symbol, not by line number — #733's own body warns that
its numbers drift, and they already have.

The closing slice

Slices 2a–5 move every rung into src/render.rs. This one deletes what is left and makes
the convergence permanent:

• handle_mouse (src/tui_main/mouse.rs) — gone, or a translate-and-delegate shim under
  ~150 lines.
• handle_mouse_click_msg, handle_mouse_drag_msg, try_route_sidebar_mouse_event
  (src/gtk/mod.rs) — same.
• handle_mouse_event (src/tui_main/shell_app.rs) — same.

Acceptance, in addition to the inherited block

• The five entry points total under 800 lines, from 4,861 at the time of filing. State
  the number.
• A test asserting both backends resolve the same ScreenLayout + point to the same
  route, verified RED by reordering one rung on one backend — the mouse twin of the
  FrameOp-sequence test Converge frame composition — ~4,500 lines laying down the same surfaces in two hand-kept orders #735 asks for. Without this, the ladder re-forks the first time
  someone adds a surface.
• No rung remains that one backend arbitrates and the other does not, or each surviving
  asymmetry carries a comment saying why it is genuinely one-sided (the folder picker is the
  known legitimate case — GTK uses a native chooser).

Acceptance criteria

Inherited verbatim from #733 — these are the rules that make a slice done:

• The rung is implemented once, in shared code (src/render.rs), and called from both
  backends.
• Both backends' bespoke arms for that rung are deleted in the same PR. A migration that
  leaves both paths is not done (GOALS.md, "How to use this doc").
• Black-box coverage on both backends — TuiDriver via driver_with_shell(TuiShellApp, …)
  in src/tui_main/shell_app.rs, and GtkDriver in src/gtk/testing.rs. Assert on rendered
  output, never on state being populated (CLAUDE.md rule 1).
• The PR states the new tests were verified RED against unfixed develop (CLAUDE.md rule 2).
• Combined production line count of the entry points above strictly decreases; the PR states
  before/after. (Converge the two mouse routers — ~4,800 lines implementing the same precedence ladder twice #733 slice 1 met this only barely — 4,994 → 4,861 — and Converge frame composition — ~4,500 lines laying down the same surfaces in two hand-kept orders #735 slice 1 did not
  meet it at all. State the numbers.)
• cargo build && cargo test && cargo clippy -- -D warnings && cargo fmt --check EXIT=0.

Scope discipline

This is one slice. Do not attempt the rungs belonging to the sibling issues listed in
Sequencing — they conflict in the same files and are queued behind this one on purpose.

Files

• src/render.rs (the shared router)
• src/tui_main/mouse.rs, src/tui_main/shell_app.rs
• src/gtk/mod.rs
• src/gtk/testing.rs (GtkDriver coverage)

Sequencing

Last of the #733 chain — after slices 2a, 2, 3, 4 and 5.

Milestone

#7 Platform-Neutral

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 24m 33s
Log: /home/john/.coord/logs/55a503bccd2b.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 3m 31s
Log: /home/john/.coord/logs/9e0e1c81012e.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: —

Summary

Verdict: request-changes

Review findings

Blocking findings

• src/tui_main/mouse.rs:816 + :855-857 — confirmed regression: TUI mouse-drag text selection is broken. The new MouseDragState.armed_target is populated as drag_state.is_active(), and route_mouse_drag's ArmedTarget rung is checked first, before EditorText. But on TUI (unlike GTK), a plain editor click arms the same drag_state with DragTarget::TextSelection (mouse.rs:2679 and :2697, drag_state.begin(quadraui::DragTarget::TextSelection { .. })), so is_active() is true for the entire duration of every text-selection drag, not just scrollbar/picker-thumb drags. route_mouse_drag therefore resolves every subsequent Drag(Left) event during a text-selection gesture to ArmedTarget, whose handler is only apply_scrollbar_drag(...) — which only reacts to quadraui::UiEvent::ScrollOffsetChanged (verified against quadraui::dispatch_mouse_drag in the pinned rev dfe0223f...: a TextSelection target emits UiEvent::TextSelectionChanged, which apply_scrollbar_drag does not match at all). The EditorText arm (apply_tui_editor_text_drag, the only place that calls engine.mouse_drag(..) to actually extend the selection) is now unreachable for the whole gesture.

  • This is a real behavior change, not a pre-existing bug: the OLD code (if drag_state.is_active() { if apply_scrollbar_drag(..) { return } }) fell through to the text-drag-to-select code when apply_scrollbar_drag reported "unhandled" (the TextSelection case). The NEW match-based router terminates in the ArmedTarget arm unconditionally, with no fallthrough.
  • GTK is not affected — it never arms DragTarget::TextSelection on its shared DragState (confirmed: no occurrence of DragTarget::TextSelection anywhere under src/gtk/), so armed_target there really does mean "scrollbar/picker thumb" as the MouseDragRoute::ArmedTarget doc comment in render.rs claims. The bug is specific to how TUI's click path (pre-existing, Route editor visual-selection drag through quadraui DragTarget::TextSelection (#508 part 3) #565) happens to reuse the same DragState for a different purpose than the new router's design assumes.
  • Concretely: click once in the editor, then move the mouse with the button held — the visual selection will not extend past the initial click point on TUI. Word-selection-extend-by-drag after a double-click is equally broken (also arms TextSelection).
  • No black-box test in this PR (or pre-existing) exercises "click in editor text, then drag" through TuiDriver with the same shared drag_state across two dispatched events, so this regression is not caught by the new or existing suite. Given the project's own testing rule ("assert on rendered output... never on state being populated"), this is exactly the kind of interaction that needed a driver.mouse_down(...); driver.mouse_move(...); assert selection painted test, and its absence is how this shipped.

• Issue Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg #756 explicitly requires (and this PR's own commit message concedes it does not meet): "The five entry points total under 800 lines." Measured directly against the branch head: handle_mouse (src/tui_main/mouse.rs) = 2,466 lines, handle_mouse_event (shell_app.rs) = 368, handle_mouse_click_msg (gtk/mod.rs) = 430, handle_mouse_drag_msg (gtk/mod.rs) = 272, try_route_sidebar_mouse_event (gtk/mod.rs) = 174 -> total 3,710 lines, against the issue's <800 target and against handle_mouse itself needing to be "gone, or a translate-and-delegate shim under ~150 lines." The commit message states this plainly ("Entry-point line count: 3,874 -> 3,710 ... The <800 target is NOT met — see the PR body"), but I don't have gh access to read the PR body's justification, and the diff itself only converges one rung (the drag-follow-through ladder) rather than the full close-out the issue title asks for ("delete handle_mouse's remains and GTK's handle_mouse_*_msg"). Flagging so the coordinator can confirm whether the PR body's follow-up plan (if any) is acceptable, or whether this needs to be re-scoped/re-titled rather than merged as "closes Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg #756."

Non-blocking concerns

• src/tui_main/mouse.rs (MouseDragRoute::TerminalContent apply) / render::in_terminal_pane_content: the old TUI drag-to-select-in-terminal code required engine.active_terminal().is_some_and(|t| t.selection.is_some()) before treating a held drag as a terminal-content selection continuation. The new shared in_terminal_pane_content is purely geometric (via route_bottom_panel_click), with no equivalent "a selection must already be armed" guard. Today this is masked by the blocking bug above (armed_target intercepts editor-originated drags first), but if that bug is fixed independently, an editor text-selection drag whose pointer strays into the terminal-panel rect could get hijacked into extending a terminal selection instead of the editor one. Worth double-checking once the primary bug is fixed.
• The bulk of handle_mouse (2,466 lines) and handle_mouse_click_msg (430 lines) is untouched by this PR — i.e. most of the "no rung remains that one backend arbitrates and the other does not" acceptance bullet is still open for the click/press rungs, not just the drag rung this PR converges. Not a regression introduced here, but worth confirming there's a filed follow-up issue tracking it, since Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg #756 is sequenced as "last of the Converge the two mouse routers — ~4,800 lines implementing the same precedence ladder twice #733 chain."

Nits

None.

[JDonaghy]

Review Complete — ⚠️ Changes Requested

Reviewer findings could not be posted directly to PR #773 (gh pr review was rejected — likely a self-review restriction). Findings are reproduced here.

Note: a completion comment was posted earlier but findings could not be extracted at that time. These are the retroactive findings.

Blocking findings

• src/tui_main/mouse.rs:816 + :855-857 — confirmed regression: TUI mouse-drag text selection is broken. The new MouseDragState.armed_target is populated as drag_state.is_active(), and route_mouse_drag's ArmedTarget rung is checked first, before EditorText. But on TUI (unlike GTK), a plain editor click arms the same drag_state with DragTarget::TextSelection (mouse.rs:2679 and :2697, drag_state.begin(quadraui::DragTarget::TextSelection { .. })), so is_active() is true for the entire duration of every text-selection drag, not just scrollbar/picker-thumb drags. route_mouse_drag therefore resolves every subsequent Drag(Left) event during a text-selection gesture to ArmedTarget, whose handler is only apply_scrollbar_drag(...) — which only reacts to quadraui::UiEvent::ScrollOffsetChanged (verified against quadraui::dispatch_mouse_drag in the pinned rev dfe0223f...: a TextSelection target emits UiEvent::TextSelectionChanged, which apply_scrollbar_drag does not match at all). The EditorText arm (apply_tui_editor_text_drag, the only place that calls engine.mouse_drag(..) to actually extend the selection) is now unreachable for the whole gesture.

  • This is a real behavior change, not a pre-existing bug: the OLD code (if drag_state.is_active() { if apply_scrollbar_drag(..) { return } }) fell through to the text-drag-to-select code when apply_scrollbar_drag reported "unhandled" (the TextSelection case). The NEW match-based router terminates in the ArmedTarget arm unconditionally, with no fallthrough.
  • GTK is not affected — it never arms DragTarget::TextSelection on its shared DragState (confirmed: no occurrence of DragTarget::TextSelection anywhere under src/gtk/), so armed_target there really does mean "scrollbar/picker thumb" as the MouseDragRoute::ArmedTarget doc comment in render.rs claims. The bug is specific to how TUI's click path (pre-existing, Route editor visual-selection drag through quadraui DragTarget::TextSelection (#508 part 3) #565) happens to reuse the same DragState for a different purpose than the new router's design assumes.
  • Concretely: click once in the editor, then move the mouse with the button held — the visual selection will not extend past the initial click point on TUI. Word-selection-extend-by-drag after a double-click is equally broken (also arms TextSelection).
  • No black-box test in this PR (or pre-existing) exercises "click in editor text, then drag" through TuiDriver with the same shared drag_state across two dispatched events, so this regression is not caught by the new or existing suite. Given the project's own testing rule ("assert on rendered output... never on state being populated"), this is exactly the kind of interaction that needed a driver.mouse_down(...); driver.mouse_move(...); assert selection painted test, and its absence is how this shipped.

• Issue Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg #756 explicitly requires (and this PR's own commit message concedes it does not meet): "The five entry points total under 800 lines." Measured directly against the branch head: handle_mouse (src/tui_main/mouse.rs) = 2,466 lines, handle_mouse_event (shell_app.rs) = 368, handle_mouse_click_msg (gtk/mod.rs) = 430, handle_mouse_drag_msg (gtk/mod.rs) = 272, try_route_sidebar_mouse_event (gtk/mod.rs) = 174 -> total 3,710 lines, against the issue's <800 target and against handle_mouse itself needing to be "gone, or a translate-and-delegate shim under ~150 lines." The commit message states this plainly ("Entry-point line count: 3,874 -> 3,710 ... The <800 target is NOT met — see the PR body"), but I don't have gh access to read the PR body's justification, and the diff itself only converges one rung (the drag-follow-through ladder) rather than the full close-out the issue title asks for ("delete handle_mouse's remains and GTK's handle_mouse_*_msg"). Flagging so the coordinator can confirm whether the PR body's follow-up plan (if any) is acceptable, or whether this needs to be re-scoped/re-titled rather than merged as "closes Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg #756."

Non-blocking concerns

• src/tui_main/mouse.rs (MouseDragRoute::TerminalContent apply) / render::in_terminal_pane_content: the old TUI drag-to-select-in-terminal code required engine.active_terminal().is_some_and(|t| t.selection.is_some()) before treating a held drag as a terminal-content selection continuation. The new shared in_terminal_pane_content is purely geometric (via route_bottom_panel_click), with no equivalent "a selection must already be armed" guard. Today this is masked by the blocking bug above (armed_target intercepts editor-originated drags first), but if that bug is fixed independently, an editor text-selection drag whose pointer strays into the terminal-panel rect could get hijacked into extending a terminal selection instead of the editor one. Worth double-checking once the primary bug is fixed.
• The bulk of handle_mouse (2,466 lines) and handle_mouse_click_msg (430 lines) is untouched by this PR — i.e. most of the "no rung remains that one backend arbitrates and the other does not" acceptance bullet is still open for the click/press rungs, not just the drag rung this PR converges. Not a regression introduced here, but worth confirming there's a filed follow-up issue tracking it, since Converge the mouse ladder slice 6: delete handle_mouse's remains and GTK's handle_mouse_*_msg #756 is sequenced as "last of the Converge the two mouse routers — ~4,800 lines implementing the same precedence ladder twice #733 chain."

Nits

None.