Status-bar / command-line messages aren't mouse-selectable (GTK can't; TUI has offset bug)

[JDonaghy]

Problem

Status bar / command line messages (the ones printed by `engine.message`, like `Use :%s/old/new/g for find & replace` after selecting certain palette entries) can't be copied via mouse cleanly on either backend:

GTK: clicking + dragging on the status row does nothing — no selection highlight, no clipboard capture. The text is effectively read-only-display, which makes error messages and status hints frustrating to copy.

TUI: selection works (presumably via Shift+drag native terminal selection, or the app's own selection path), but the visible selection highlight is offset by the width of the activity bar + sidebar. Hiding the sidebar (`:set nosidebar` or toggling the explorer) makes the problem less bad — suggesting the selection math is using absolute screen columns without accounting for the editor-column left offset.

Expected

Both backends: click-drag on any status-bar or command-line text should produce a visible selection highlight that actually matches the cells the mouse traversed, and the selection should be copyable to clipboard.

Suspected Causes

GTK: the status bar's DrawingArea (`draw_window_status_bar` / global status bar / command line) doesn't have a drag gesture controller that tracks selection state + renders a selection rectangle. All clickable behavior is segment-level (LSP status chip, filetype picker, etc.) with no text-selection path.

TUI: `src/tui_main/mouse.rs` — search for `hover_selecting` and the command-line / status-line selection path. The offset-by-sidebar-width symptom suggests the selection anchor is stored as absolute screen col but rendered relative to the editor-column origin (or vice versa).

Files

• GTK: `src/gtk/draw.rs` (status bar draws), `src/gtk/mod.rs` (status bar DrawingArea setup)
• TUI: `src/tui_main/mouse.rs` (selection math), `src/tui_main/render_impl.rs` (status bar + cmd line render)
• Engine: `src/render.rs::CommandLineData`, `src/core/engine/mod.rs` for `message` / selection state

Priority

Minor UX papercut but frequent (can't copy error messages easily). Not blocking anything.

[JDonaghy]

Blocker identified and filed: quadraui#705.

This is not a vimcode bug on the GTK side — it is structurally impossible there today. Surface::CommandLine can be painted but not interrogated: there is no CommandLineLayout in quadraui at all (verified 2026-09-03 against quadraui origin/develop @ 17df15d), so there is no character-offset hit test for a GTK selection to be built on. TUI gets selection by an inverted-cell read-back pass, which is a terminal-only trick.

The #752 convergence slice reached this conclusion and recorded it at src/tui_main/mouse.rs:1620 — "That is a quadraui gap, not a vimcode transcription: the fix is a CommandLineLayout::hit_test in quadraui, then one shared rung here — not ~80 lines of new GTK-specific selection code" — but never filed the upstream issue, so this issue has been sitting without its blocker attached. Surfaced by the irreducible-surface aggregation (docs/IRREDUCIBLE_SURFACE.md, PR #787).

Sequence: quadraui#705 lands → vimcode collapses the one-sided rung in mouse.rs into a single shared one and deletes the per-backend cmd_sel/cmd_dragging state → this issue's GTK half closes. The TUI offset bug this issue also names is separable and can be fixed independently.

Do not fix this by adding GTK-side selection code — that is the per-backend code the Platform-Neutrality Rule exists to prevent, and it is why the blocker was filed upstream instead.

[JDonaghy]

Coordinator Assignment

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

Briefing

Issue #194: Status-bar / command-line messages aren't mouse-selectable (GTK can't; TUI has offset bug)

Problem

Status bar / command line messages (the ones printed by `engine.message`, like `Use :%s/old/new/g for find & replace` after selecting certain palette entries) can't be copied via mouse cleanly on either backend:

GTK: clicking + dragging on the status row does nothing — no selection highlight, no clipboard capture. The text is effectively read-only-display, which makes error messages and status hints frustrating to copy.

TUI: selection works (presumably via Shift+drag native terminal selection, or the app's own selection path), but the visible selection highlight is offset by the width of the activity bar + sidebar. Hiding the sidebar (`:set nosidebar` or toggling the explorer) makes the problem less bad — suggesting the selection math is using absolute screen columns without accounting for the editor-column left offset.

Expected

Both backends: click-drag on any status-bar or command-line text should produce a visible selection highlight that actually matches the cells the mouse traversed, and the selection should be copyable to clipboard.

Suspected Causes

GTK: the status bar's DrawingArea (`draw_window_status_bar` / global status bar / command line) doesn't have a drag gesture controller that tracks selection state + renders a selection rectangle. All clickable behavior is segment-level (LSP status chip, filetype picker, etc.) with no text-selection path.

TUI: `src/tui_main/mouse.rs` — search for `hover_selecting` and the command-line / status-line selection path. The offset-by-sidebar-width symptom suggests the selection anchor is stored as absolute screen col but rendered relative to the editor-column origin (or vice versa).

Files

• GTK: `src/gtk/draw.rs` (status bar draws), `src/gtk/mod.rs` (status bar DrawingArea setup)
• TUI: `src/tui_main/mouse.rs` (selection math), `src/tui_main/render_impl.rs` (status bar + cmd line render)
• Engine: `src/render.rs::CommandLineData`, `src/core/engine/mod.rs` for `message` / selection state

Priority

Minor UX papercut but frequent (can't copy error messages easily). Not blocking anything.

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 11m 58s
Log: /home/john/.coord/logs/c7e64ed975d9.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 3m 21s
Log: /home/john/.coord/logs/090bfa42ebc7.log

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

• The new test (message_row_click_anchors_selection_relative_to_editor_left, src/tui_main/mouse.rs) asserts on the cmd_sel state value returned by handle_mouse, not on painted screen content — which is literally the anti-pattern CLAUDE.md's "Testing (CRITICAL)" section calls out ("Assert on rendered output — never on state being populated"). I verified this isn't a rubber-stamp concern by checking whether a rendered-content assertion is even achievable here: render_command_line (src/tui_main/panels.rs:397-404) implements the selection highlight as a pure fg/bg color swap with no distinguishing text, and the driver's screen() only dumps text — the same limitation the existing render_content_paints_command_mode_text_with_cursor_via_shell_app test (shell_app.rs:5941) explicitly documents for the cursor-inversion case ("invisible to screen()'s text dump"). There's also a directly analogous precedent already in this codebase, mouse_drag_resizes_sidebar_via_handle_mouse_event (shell_app.rs:7436), which asserts on app.sidebar_width/app.dragging_sidebar state for the same documented reason. Given that precedent and the genuine tooling gap, I'm not blocking on this, but a driver-level test that at least exercises TuiShellApp::handle_mouse_event (rather than calling the free handle_mouse fn directly, bypassing the production dispatch path) would sit closer to the mandated tier and is worth doing in a follow-up.
• The commit intentionally leaves the GTK half of Status-bar / command-line messages aren't mouse-selectable (GTK can't; TUI has offset bug) #194 unfixed, citing CLAUDE.md's Platform-Neutrality Rule and the pre-existing Converge the mouse ladder slice 2: chrome — tab bar, breadcrumbs, status bar, menu row / command centre #752 in-file precedent (GTK has no cmd_sel/drag-selection state or character-offset hit test on its command line — building one from scratch would be ~80 lines of new GTK-specific code, whereas the correct fix is a CommandLineLayout::hit_test primitive in quadraui first). I verified this reasoning against the actual code (route_cmdline_selection_key in src/render.rs:3820 is explicitly TUI-only per its own doc comment) and it's architecturally sound. The commit message says a quadraui issue "needs" to be filed before GTK work proceeds — I can't verify from this review session whether that tracking issue actually exists yet. Worth the coordinator double-checking that Status-bar / command-line messages aren't mouse-selectable (GTK can't; TUI has offset bug) #194 isn't closed outright by this PR (only the TUI half is fixed) and that a quadraui-side follow-up issue is filed/tracked so the GTK half doesn't silently fall off backlog.

Nits

• dispatch_left_click_for_cmd_sel (src/tui_main/mouse.rs, new helper) carries #[allow(clippy::too_many_arguments)] but only takes 5 parameters, well under clippy's default 7-arg threshold — the attribute is dead weight copied from a different context (the file's other multi-arg helpers). Harmless (won't fail cargo clippy -- -D warnings), just noise.

Verification notes

• Confirmed via git diff <merge-base> FETCH_HEAD that the diff shown for review is complete and accurate — only src/tui_main/mouse.rs changed (135 insertions / 6 deletions), no CLAUDE.md or other coordinator-owned docs touched.
• Traced editor_left's definition (ab_width + sidebar_width + 1 when the sidebar is visible, mouse.rs:307) against render_command_line's cell-vector indexing (panels.rs, 0-based from area.x) and bottom_chrome_rects_for_shell_content's area param (== main_content_bounds, already carved of activity-bar/sidebar width) — confirmed chrome.cmd.x == editor_left, so the fix's premise (selection anchor must be editor_left-relative, not absolute) is correct.
• Traced the copy-to-clipboard consumer (route_cmdline_selection_key, render.rs:3820) — it indexes directly into engine.message/engine.command_buffer chars using the cmd_sel tuple as char offsets, confirming cmd_sel was always meant to be a 0-based char index and the pre-fix absolute-screen-column value was a genuine bug, not just a display nit.
• Manually checked the new test's arithmetic (ACTIVITY_BAR_WIDTH = 3, SIDEBAR_WIDTH = 30, autohide_panels defaults false) — the expected 34-column offset and the dispatch_left_click_for_cmd_sel call's 32 positional arguments both line up against handle_mouse's actual signature.
• Read the commit message on the fetched branch (4f43426): it explicitly states the new test was "confirmed to fail against the unfixed code," satisfying the project's RED-before-fix requirement, and explains the GTK-scope decision — both align with what I independently verified from the code.
• Per instructions, did not run cargo test/cargo build/cargo clippy — static review only (build/test is the separate pre-merge smoke gate's job).

[JDonaghy]

Review Complete — ✅ Approved

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

None.

Non-blocking concerns

• The new test (message_row_click_anchors_selection_relative_to_editor_left, src/tui_main/mouse.rs) asserts on the cmd_sel state value returned by handle_mouse, not on painted screen content — which is literally the anti-pattern CLAUDE.md's "Testing (CRITICAL)" section calls out ("Assert on rendered output — never on state being populated"). I verified this isn't a rubber-stamp concern by checking whether a rendered-content assertion is even achievable here: render_command_line (src/tui_main/panels.rs:397-404) implements the selection highlight as a pure fg/bg color swap with no distinguishing text, and the driver's screen() only dumps text — the same limitation the existing render_content_paints_command_mode_text_with_cursor_via_shell_app test (shell_app.rs:5941) explicitly documents for the cursor-inversion case ("invisible to screen()'s text dump"). There's also a directly analogous precedent already in this codebase, mouse_drag_resizes_sidebar_via_handle_mouse_event (shell_app.rs:7436), which asserts on app.sidebar_width/app.dragging_sidebar state for the same documented reason. Given that precedent and the genuine tooling gap, I'm not blocking on this, but a driver-level test that at least exercises TuiShellApp::handle_mouse_event (rather than calling the free handle_mouse fn directly, bypassing the production dispatch path) would sit closer to the mandated tier and is worth doing in a follow-up.
• The commit intentionally leaves the GTK half of Status-bar / command-line messages aren't mouse-selectable (GTK can't; TUI has offset bug) #194 unfixed, citing CLAUDE.md's Platform-Neutrality Rule and the pre-existing Converge the mouse ladder slice 2: chrome — tab bar, breadcrumbs, status bar, menu row / command centre #752 in-file precedent (GTK has no cmd_sel/drag-selection state or character-offset hit test on its command line — building one from scratch would be ~80 lines of new GTK-specific code, whereas the correct fix is a CommandLineLayout::hit_test primitive in quadraui first). I verified this reasoning against the actual code (route_cmdline_selection_key in src/render.rs:3820 is explicitly TUI-only per its own doc comment) and it's architecturally sound. The commit message says a quadraui issue "needs" to be filed before GTK work proceeds — I can't verify from this review session whether that tracking issue actually exists yet. Worth the coordinator double-checking that Status-bar / command-line messages aren't mouse-selectable (GTK can't; TUI has offset bug) #194 isn't closed outright by this PR (only the TUI half is fixed) and that a quadraui-side follow-up issue is filed/tracked so the GTK half doesn't silently fall off backlog.

Nits

• dispatch_left_click_for_cmd_sel (src/tui_main/mouse.rs, new helper) carries #[allow(clippy::too_many_arguments)] but only takes 5 parameters, well under clippy's default 7-arg threshold — the attribute is dead weight copied from a different context (the file's other multi-arg helpers). Harmless (won't fail cargo clippy -- -D warnings), just noise.

Verification performed: confirmed the diff shown matches git diff <merge-base> FETCH_HEAD exactly (only src/tui_main/mouse.rs changed, no coordinator-owned docs touched); traced editor_left's definition against render_command_line's indexing and bottom_chrome_rects_for_shell_content's bounds to confirm the fix's premise is correct; traced the clipboard-copy consumer (route_cmdline_selection_key) to confirm cmd_sel was always meant to be a 0-based char index; manually checked the new test's offset arithmetic and the helper's 32 positional arguments against handle_mouse's actual signature; read the fetched branch's commit message, which states the test was confirmed RED against unfixed code. Did not run cargo test/build/clippy per instructions (static review only).