Split-pane divider drag is broken in both TUI and GTK (falls through to text-selection)

[JDonaghy]

Summary

Split-pane divider drag-to-resize is completely non-functional in both the
TUI and GTK backends. Clicking and dragging where the divider should be does
not grab/move the divider at all — instead the drag falls straight through
and starts a text-selection in the editor content underneath.

Discovered during the smoke test of #550 (unify GTK/TUI window-rect
coordinate conventions). Initially suspected as a regression from that
branch, but confirmed pre-existing on develop (reproduced on a fresh
develop build, not just the #550 branch) — so this is a separate,
standalone bug, not caused by #550.

Repro steps (TUI)

1. Launch TUI mode: vimcode --tui <file>
2. Open a vertical split: :vsplit
   • Expected: a visible divider line rendered between the two panes.
   • Actual: no divider is rendered at all.
3. Repeat with a horizontal split: :split
   • Same result — no visible divider line either.
4. Click and drag in the area where the divider should logically sit (the
   boundary between the two panes).
   • Expected: grabs the divider and resizes the panes.
   • Actual: the drag instead starts a text-selection in the editor pane
     underneath — the divider has no hit-test region reacting to the drag
     at all.

Repro steps (GTK)

1. Launch GTK mode: vimcode <file>
2. Open a split and attempt to drag the divider.
   • Actual: identical symptom to TUI — the drag starts a text-selection in
     the editor instead of grabbing/moving the divider.
   • (Divider visibility in GTK was not separately re-confirmed; only that
     dragging is non-functional with the same failure mode as TUI.)

Why this is one issue, not two backend-specific bugs

Both backends show the exact same failure mode (drag falls through to
editor text-selection), which is suspicious — either there's a shared
divider hit-test/drag-state code path both backends route through that's
broken, or the same class of bug was independently introduced/exists in
both backends' divider handling. Worth checking whether a hit-test region
for the divider exists/registers at all before checking coordinate math,
since the symptom looks like the divider consumes no events rather than
consuming them at the wrong offset.

Suspected files/areas

• src/tui_main/render_impl.rs — divider position computation/rendering
  (grep GroupDivider, divider position/cross_start)
• src/tui_main/mouse.rs — divider hit-test and drag handling (grep
  divider)
• src/gtk/ — divider/split drag handling
• Any shared engine/render code both backends call for divider hit-test or
  drag-state, per the Platform-Neutral push (see GOALS.md /
  Platform-Neutrality Rule in CLAUDE.md) — check there before writing new
  per-backend code.

Impact

Users cannot resize split panes via mouse drag in either backend today —
this is a real, reproducible usability regression/gap independent of #550.

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Fixed #582: WindowLayout (vim :split/:vsplit panes) had zero divider hit-test/drag support — only the separate GroupLayout (editor-group split) feature had it. Mirrored GroupLayout's divider/ratio methods onto WindowLayout in core/window.rs, added shared render::divider_hit_test/divider_ratio_from_pos helpers used by both new window-divider code AND refactored into the pre-existing (duplicated) group-divider hit-test in both backends, wired thin per-backend mouse handling in gtk/mod.rs and tui_main/{mod,mouse}.rs. Also fixed a related dead-code bug: Ctrl-W +/-/</>/=/_/| resize commands only ever touched group_layout (no-op for window splits); rewired with window-split-first/group-split-fallback so the pre-existing group-split tests (tests/vim_compat_batch.rs) still pass while window splits now work too. Checked quadraui first per Platform-Neutrality Rule — no N-way divider-tree primitive exists yet (only a 2-pane Split); flagged as a follow-up quadraui issue rather than blocking. Full build/clippy/fmt/test suite clean (2015+2151 unit tests + all integration suites pass, zero new warnings — pre-existing unrelated snake_case/unused-import warnings in tests.rs/git.rs predate this change). Added new tests: 6 core::window unit tests, 1 TUI mouse-drag test, 3 new tests/wincmd.rs assertions. Durable findings recorded via coord context (pinned).

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 1h 50m

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Smoke test FAILED: #582 divider drag broken in 3 of 4 combos (TUI hsplit + GTK vsplit have no divider at all; TUI vsplit divider is flaky ~50%); only GTK hsplit fully works

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Fixed the 3 broken smoke-test combos. Root cause: window-divider RENDER position and HIT-TEST position never agreed (not an asymmetric-wiring bug as originally suspected). TUI's visible mark (from pre-existing render_separators) sits at position-1, but hit-test only accepted position exactly -> 100% miss for :split (no glyph at all there, status line is the only visible mark and sits at position-1), ~50% flaky for :vsplit (visible glyph at position-1, user aim varies). GTK painted literally nothing for :vsplit (only :split incidentally worked via the per-window status bar). Fixes: (1) tui_main/mouse.rs widened window-divider hit-test tolerance from (0.0,1.0) to (1.0,1.0) both axes so both the visible glyph and the boundary cell register; updated the existing :vsplit test (its 'one column off must miss' case encoded the exact bug) and added a new :split horizontal test since that axis had zero coverage. (2) render.rs added divider_to_split(), converting a divider into the (quadraui::Split, quadraui::Rect) pair needed for backend.draw_split() -- quadraui's existing divider-line primitive, already wired for both backends but unused by the original #582 commit. (3) gtk/mod.rs paints the :vsplit divider line via divider_to_split (horizontal left alone, already working). All builds clean (--no-default-features and default/gui), clippy clean both feature sets, full test suite green: 2154 (vcd bin) + 2015 (lib) + all integration suites, 0 failures. 2 new unit tests in render.rs, 1 new + 1 updated test in tui_main/mouse.rs.

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Smoke #582 iter-2: FAILED — TUI both orientations + GTK hsplit pass, but GTK vsplit divider still has zero render/hit-test (identical to iter-1 despite commit 546a212)

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Fixed #582 GTK :vsplit divider (commit aeee4ca). Root cause was NOT the paint call the reviewer suspected — per their advice I verified divider_to_split() IS invoked on the GTK vsplit render path before re-deriving logic. Real cause: coordinate-frame mismatch. render_content anchors editor_bounds at AppShellLayout::main_content_bounds (absolute — offset right by activity bar + sidebar, down by title bar, the #550 convention), while all four divider hit-test/drag handlers rebuilt content_bounds at (0,0) with a different height formula. Clicks arrive in absolute DA coords (single-DA #217), so the hit band sat ~one activity-bar-width left of the painted line: vsplit unhittable -> press fell through to text-selection. Fix: cache the exact (editor_bounds, tab_bar_h) each render_content pass painted with; hit-test/drag against it via painted_editor_bounds(), making hit-test-agrees-with-paint true by construction instead of two hand-synced formulas. Applied to all 4 sites (window AND editor-group divider, press AND drag-motion) since the group path had the identical latent bug. Also corrected an iteration-1 misdiagnosis: GTK :split never 'worked via the status bar' — it just had a smaller (y-only) error so a status-bar click hit the 6px band by luck. Both axes were broken by the same bug, so the Vertical-only render filter is dropped and a real divider line is now painted on both axes. Added 2 regression tests in render.rs pinning that hit band + painted rect both track axis_start; verified non-vacuous by re-injecting the origin bug (test fails) and restoring (passes). Gates: cargo build clean (no warnings), clippy -D warnings clean, cargo fmt --check clean, full cargo test --no-default-features suite passes (exit 0, 0 failures). GTK rendering itself is unverifiable headless — needs human smoke on real hardware.

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

Smoke passed: TUI+GTK divider render and drag-resize both confirmed working on branch

[JDonaghy]

Coordinator: Assignment Complete

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

Summary

GTK divider hit-test/paint coordinate-frame fix (aeee4ca) verified correct, non-vacuous tests confirmed

Verdict: approve

Review findings

Re-review (iteration 2) — issue #582, commit aeee4ca

Scope: reviewed only the fix pushed since the last round —
aeee4ca fix(#582): hit-test GTK dividers in the frame they're painted in
(src/gtk/mod.rs +112/-52, src/render.rs +84 mostly new tests). The prior
two commits (54376cf, 546a212) were in-scope for iteration 1 and not
re-reviewed here.

What the fix does

The iteration-2 smoke found GTK :vsplit still had no visible divider and
still fell through to text-selection. Root cause per the commit: the paint
call (divider_to_split, added in 546a212) painted the divider using
editor_bounds anchored at AppShellLayout::main_content_bounds (absolute,
offset by activity bar/sidebar/title bar — from #550), while every
hit-test/drag handler independently re-derived content_bounds at a hardcoded
(0.0, 0.0) origin with a different height formula (gtk_editor_bottom
vs the renderer's editor_area_h). Paint and hit-test disagreed on where the
divider was, so :vsplit was unreachable.

Fix: App now caches the exact (editor_bounds, tab_bar_h) that the last
render_content pass painted with (cached_editor_bounds: Cell<Option<(WindowRect, f64)>>), exposed via painted_editor_bounds(). All four divider call sites
(group-divider hit-test, window-divider hit-test, group-divider drag,
window-divider drag) now read this cached value instead of recomputing their
own bounds. render_content also now paints window dividers on both axes
(dropping the old Vertical-only filter), and two new regression tests in
render.rs pin the axis_start-anchored hit-test/paint invariant.

Verification performed

• Traced all 4 call sites in src/gtk/mod.rs (lines ~4364, ~4406, ~4778,
  ~4798 in the branch checkout) — braces/control flow are correct, each
  falls through to the pre-existing text-selection path when
  painted_editor_bounds() is None or no divider hits, matching prior
  behavior for "no divider" clicks.
• Confirmed cached_editor_bounds.set(...) at the render_content site
  (line ~7761) stores exactly the editor_bounds/tab_bar_h used
  immediately after for calculate_group_window_rects and
  build_screen_layout — hit-test-agrees-with-paint is now true by
  construction, as claimed.
• Confirmed WindowRect is #[derive(..., Copy)], so Cell<Option<(WindowRect, f64)>> is valid, and Cell was already imported (use std::cell::{Cell, RefCell}).
• Confirmed the previously-inlined tab_bar_h computation
  (tab_row_h = (lh*1.6).ceil(), +lh if breadcrumbs) is identical to the
  shared render::tab_bar_height_px now used to populate the cache — no
  behavior change from that substitution.
• Hand-checked both new render.rs tests against the actual
  divider_hit_test / divider_ratio_from_pos / divider_to_split
  implementations line-by-line (not just trusting the assertions):
  • divider_hit_test_follows_axis_start_not_screen_origin: position 600,
    axis_start 300 → hit at x=600 (Some(0)), miss at the "origin-zero"
    x=300 (None), drag ratio at x=450 → 0.25. All arithmetically correct
    against the real divider_hit_test/divider_ratio_from_pos bodies —
    genuinely non-vacuous, would fail if the origin bug were reintroduced.
  • divider_to_split_preserves_absolute_origin: ratio 0.5, rect
    (300, 40, 600, 500) — matches divider_to_split's Vertical arm
    exactly.
• Confirmed width/height params on handle_mouse_click_msg and
  handle_mouse_drag_msg are still used elsewhere in those functions (no
  now-unused-parameter warning from removing the local content_bounds
  recomputation).
• Confirmed gtk_editor_bottom (the old, now-superseded-for-dividers height
  formula) is still called from other unrelated sites, so it isn't now dead
  code under -D warnings.
• rustfmt --check on the branch's render.rs is clean; the two
  reformatted assert! one-liners in the diff are pure cargo fmt noise
  around pre-existing tests, not logic changes.
• Confirmed this commit only touches src/gtk/mod.rs and src/render.rs —
  TUI (src/tui_main/*) is untouched, so no regression risk there from this
  commit.

Non-blocking observations (pre-existing, out of scope for #582)

Two other GTK call sites still rebuild content_bounds at a hardcoded
WindowRect::new(0.0, 0.0, ...) instead of using painted_editor_bounds():
src/gtk/mod.rs ~line 1800 (scroll-wheel hovered-window routing, keyed off
last_editor_pointer) and ~line 8843 (tab_tooltip_hit_test). Both predate
this PR (identical on origin/develop) and are unrelated features (scroll
routing / tab tooltips, not divider drag), so they're correctly out of scope
here — flagging only in case a future issue wants to sweep the same
frame-mismatch class of bug. Also worth noting last_editor_pointer appears
to only ever be read, never .set(), anywhere in the crate — likely
pre-existing dead state, also out of scope.

Verdict

The fix correctly identifies and resolves the coordinate-frame mismatch
between GTK's divider paint and hit-test/drag paths, is scoped tightly to
the failure the iteration-2 smoke reported, adds real (non-vacuous)
regression coverage for the exact invariant it relies on, and introduces no
regressions to TUI or to unrelated GTK code paths. Approving.