TUI runs two double-click detectors — adopt quadraui DoubleClickDetector and delete the hand-rolled 400ms window

[JDonaghy]

Problem

quadraui ships DoubleClickDetector (quadraui/src/dispatch.rs:870), and TuiBackend already embeds one (tui/backend.rs:129, :235) and emits UiEvent::DoubleClick. src/tui_main/shell_app.rs handles UiEvent::DoubleClick at 8 sites.

At the same time, src/tui_main/mouse.rs threads last_click_time / last_click_pos through handle_mouse (:262-263) and re-detects double-clicks with a hand-rolled 400 ms window at :572, :1958, :2076, :2158.

Two double-click detectors are running on one backend, with independent timing state that can disagree. grep -rn DoubleClickDetector src/ → 0.

Fix

Delete the hand-rolled detection. Route all four sites through the UiEvent::DoubleClick the backend already emits, matching the 8 sites in shell_app.rs that consume it. Drop last_click_time / last_click_pos from handle_mouse's parameter list (it currently takes 33 parameters — this is a small step toward that being tractable).

Check the GTK side for the same pattern while here: src/app.rs:1182-1292 handles double/ctrl click.

Acceptance

• Black-box tests required — double-click word selection in the editor, and on whichever of the four sites (:1958, :2076, :2158) are user-reachable.
• State in the PR that the new tests fail against unfixed develop.
• Both backends per the multi-backend rule.

[JDonaghy]

Before you start: re-verify the citations, do not trust them

Every file:line in this issue was measured on develop @ ee26268 (2026-09-04) by an audit, not by reading the tree you will check out.

They will have drifted by the time you pick this up. This issue sits in a serialised chain, and several entries ahead of it move code on purpose — #812 deletes ~1,300 lines from src/render.rs, #813 retypes fields in src/app.rs, #785 and #814 delete whole functions. Anything filed after those shifts.

So:

• Locate by symbol, not by line. grep -n "fn build_screen_layout_with_breadcrumb_row" src/render.rs, not "go to line 12886". GOALS.md already carries this rule for the same reason — it cites no line numbers on purpose.
• Re-measure any count before you use it. Line totals here came from python3 scripts/prod_lines.py and scripts/native_lines.py at a named revision. Re-run them rather than quoting the number in this issue. GOALS.md: "regenerate them with the script rather than trusting the table."
• Size the branch from what you find, not from the figure here. The counts are evidence that a problem is large, not estimates of a diff.

If a finding does not reproduce, say so — that is a useful result

This issue was generated from an automated audit. Some of its claims are wrong. Today alone, two confident findings in the same audit chain did not survive checking: a "1,671 byte-identical lines" figure measured out at ~85, and a "zero commits of pin lag" reading was taken against a stale local ref and was actually 42.

If the problem described here is already fixed, was never real, or is real but different from the description: comment with what you actually found and stop. Do not implement around a bad premise to make the issue closeable. A correction is worth more than a merged PR built on a wrong claim.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #817: TUI runs two double-click detectors — adopt quadraui DoubleClickDetector and delete the hand-rolled 400ms window

Problem

quadraui ships DoubleClickDetector (quadraui/src/dispatch.rs:870), and TuiBackend already embeds one (tui/backend.rs:129, :235) and emits UiEvent::DoubleClick. src/tui_main/shell_app.rs handles UiEvent::DoubleClick at 8 sites.

At the same time, src/tui_main/mouse.rs threads last_click_time / last_click_pos through handle_mouse (:262-263) and re-detects double-clicks with a hand-rolled 400 ms window at :572, :1958, :2076, :2158.

Two double-click detectors are running on one backend, with independent timing state that can disagree. grep -rn DoubleClickDetector src/ → 0.

Fix

Delete the hand-rolled detection. Route all four sites through the UiEvent::DoubleClick the backend already emits, matching the 8 sites in shell_app.rs that consume it. Drop last_click_time / last_click_pos from handle_mouse's parameter list (it currently takes 33 parameters — this is a small step toward that being tractable).

Check the GTK side for the same pattern while here: src/app.rs:1182-1292 handles double/ctrl click.

Acceptance

• Black-box tests required — double-click word selection in the editor, and on whichever of the four sites (:1958, :2076, :2158) are user-reachable.
• State in the PR that the new tests fail against unfixed develop.
• Both backends per the multi-backend rule.

[JDonaghy]

Coordinator: Assignment Complete

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

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 3m 6s
Log: /home/john/.coord/logs/96cfd2f31d81.log

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: request-changes

Review findings

Blocking findings

• Incomplete black-box coverage against the issue's own Acceptance section. The issue explicitly requires: "double-click word selection in the editor, and on whichever of the four sites (:1958, :2076, :2158) are user-reachable." The PR removes the hand-rolled 400ms detector at five call sites in src/tui_main/mouse.rs (find/replace input, ext-panel row, git/source-control sidebar row, settings row, editor word-select — per the commit's own description: "read it directly at all five sites") but adds black-box tests for only two: the editor word-select and the settings-row toggle. The ext-panel double-click (SidebarOwner::Extensions arm, engine.handle_ext_panel_double_click(), formerly around :1958) and the git/source-control sidebar double-click (SidebarOwner::SourceControl/route_sc_sidebar_click arm, engine.handle_sc_sidebar_ui_event(double_ev), formerly around :2076) are both ordinary, user-reachable interactions (double-click an item in the Extensions panel; double-click a changed file in the Source Control sidebar) with real, user-visible side effects, and both already have test fixtures/patterns to build on in this same file (app_with_ext_panel() at shell_app.rs:4518, and render_content_paints_source_control_panel_via_shell_app at shell_app.rs:7400 showing the SC panel is already exercised in tests) — so this isn't a "too hard to set up" situation. The PR's own commit message doesn't state that these two sites are exempt or explain why they're excluded; per this project's CLAUDE.md ("Pure refactors and internal-only changes are exempt — say so in the PR if that applies... the adversarial reviewer... rejects behaviour-changing PRs that lack one"), and per the issue's own explicit acceptance bullet naming these exact sites, this is a request-changes: either add driver tests for the ext-panel and SC-sidebar double-click sites, or state explicitly in the PR why they're not user-reachable / are exempt.

Non-blocking concerns

• The find/replace input double-click site (:572 in the issue's numbering) also changed behavior (same hand-rolled-detector-to-shared-flag swap) and is easily user-reachable (open Find/Replace, double-click inside the input field to select a word), but has no dedicated black-box test either. It's not named in the Acceptance section's "four sites" list, so I'm not treating it as blocking, but it's the same category of gap as the two sites above and would be cheap to close alongside them.

Nits

• None.

[JDonaghy]

Review Complete — ⚠️ Changes Requested

Reviewer findings could not be posted directly to PR #844 (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

• Incomplete black-box coverage against the issue's own Acceptance section. The issue explicitly requires: "double-click word selection in the editor, and on whichever of the four sites (:1958, :2076, :2158) are user-reachable." The PR removes the hand-rolled 400ms detector at five call sites in src/tui_main/mouse.rs (find/replace input, ext-panel row, git/source-control sidebar row, settings row, editor word-select — per the commit's own description: "read it directly at all five sites") but adds black-box tests for only two: the editor word-select and the settings-row toggle. The ext-panel double-click (SidebarOwner::Extensions arm, engine.handle_ext_panel_double_click(), formerly around :1958) and the git/source-control sidebar double-click (SidebarOwner::SourceControl/route_sc_sidebar_click arm, engine.handle_sc_sidebar_ui_event(double_ev), formerly around :2076) are both ordinary, user-reachable interactions (double-click an item in the Extensions panel; double-click a changed file in the Source Control sidebar) with real, user-visible side effects, and both already have test fixtures/patterns to build on in this same file (app_with_ext_panel() at shell_app.rs:4518, and render_content_paints_source_control_panel_via_shell_app at shell_app.rs:7400 showing the SC panel is already exercised in tests) — so this isn't a "too hard to set up" situation. The PR's own commit message doesn't state that these two sites are exempt or explain why they're excluded; per this project's CLAUDE.md ("Pure refactors and internal-only changes are exempt — say so in the PR if that applies... the adversarial reviewer... rejects behaviour-changing PRs that lack one"), and per the issue's own explicit acceptance bullet naming these exact sites, this is a request-changes: either add driver tests for the ext-panel and SC-sidebar double-click sites, or state explicitly in the PR why they're not user-reachable / are exempt.

Non-blocking concerns

• The find/replace input double-click site (:572 in the issue's numbering) also changed behavior (same hand-rolled-detector-to-shared-flag swap) and is easily user-reachable (open Find/Replace, double-click inside the input field to select a word), but has no dedicated black-box test either. It's not named in the Acceptance section's "four sites" list, so I'm not treating it as blocking, but it's the same category of gap as the two sites above and would be cheap to close alongside them.

Nits

• None.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dell64
Status: done
Exit code: 0
Duration: 25m 1s
Log: /home/john/.coord/logs/9eb7ec765886.log

[JDonaghy]

Coordinator: Assignment Complete

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

[JDonaghy]

Coordinator: Assignment Complete

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