fix: dedupe terminal pane focus + selection into engine method (#429) - #445
Merged
Conversation
Both backends were inlining the same three steps after a content click
on a non-split terminal pane:
engine.terminal_has_focus = true;
engine.terminal_scroll_reset();
if let Some(term) = engine.active_terminal_mut() {
term.selection = Some(TermSelection { ..click_cell });
}
Plus `handle_terminal_split_click` did the same work twice (once for
LeftPane, once for RightPane).
Extract `Engine::handle_terminal_pane_click(col, row)` as the single
source of truth. TUI mouse handler consumes it in the non-split
fallback (`mouse.rs:2069`). The split method's LeftPane / RightPane
arms now delegate to it after setting `terminal_active`.
Per the issue scope, GTK consumption (mod.rs:6798-6811) is a follow-up;
no GTK changes in this PR.
Refs #429
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
JDonaghy
added a commit
that referenced
this pull request
Jul 18, 2026
…ndor quadraui#452 vendored vt100 0.16.2 with its unicode-width bound loosened (vendor/vt100-0.16.2-patched/) and patches it via [patch.crates-io] in quadraui's OWN Cargo.toml to resolve a conflict with ratatui 0.29's exact unicode-width=0.2.0 pin. But Cargo only honors [patch] sections declared in the root manifest of the workspace actually being built — quadraui's patch has zero effect on vimcode's separate build, so vimcode's own Cargo.toml needs a matching [patch.crates-io] entry pointing at the same vendored copy. Confirmed by quadraui#452's own commit message, which explicitly flagged this vimcode-side companion change as needed and out of scope for that session. With this, `cargo build --features gui` gets past dependency resolution (previously failed here with a unicode-width version conflict) — but still does not succeed end-to-end. It now hits a separate, unrelated, much larger issue: quadraui's `tui` feature currently pulls in ratatui 0.30 (bumped independently of #452 or #445, at some point between quadraui ebb4ab7 and current develop), which split Frame/Buffer/Rect into a new `ratatui-core` crate. vimcode's own TUI rendering code (src/tui_main/panels.rs, render_impl.rs, quadraui_tui.rs, mod.rs — ~46 call sites total) is still written directly against ratatui 0.29's types and is incompatible with quadraui's now-ratatui-core-based `Backend::enter_frame_scope` signature. That's a real, separate migration (bump vimcode's own ratatui pin and update every touched call site) — tracked separately, not attempted here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
JDonaghy
added a commit
that referenced
this pull request
Jul 19, 2026
The #587 regression (GTK global accelerators — Ctrl+Shift+P command palette, Ctrl+B sidebar, Ctrl+P quick-open — silently do nothing) has repeatedly slipped through Test-stage smoke as a build-against-stale- quadraui trap: quadraui#445's accelerator-dispatch fix is a behavioural change with no new public symbol, so a checkout that predates it still compiles vimcode cleanly and only fails at runtime. The vimcode side of #587 is already complete and correct on this branch (register_panel_accelerators wired into ShellApp::setup, UiEvent:: Accelerator handled in ShellApp::handle) — nothing there needed changing. The remaining failure mode was purely environmental: an artifact built against a quadraui checkout lacking #445. Add a build.rs guard that reads the sibling quadraui GTK key-controller source and hard-fails the build with actionable remediation if it does not call `match_keypress` (the Backend method #445 consults on the live key path). Converts the silent runtime breakage into a loud build error. Falls back to a warning (never a false failure) if the path dep points elsewhere. Verified: passes against quadraui develop tip (has #445); full lib suite green on both gui and default/TUI feature sets. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
JDonaghy
added a commit
that referenced
this pull request
Jul 20, 2026
…ndor quadraui#452 vendored vt100 0.16.2 with its unicode-width bound loosened (vendor/vt100-0.16.2-patched/) and patches it via [patch.crates-io] in quadraui's OWN Cargo.toml to resolve a conflict with ratatui 0.29's exact unicode-width=0.2.0 pin. But Cargo only honors [patch] sections declared in the root manifest of the workspace actually being built — quadraui's patch has zero effect on vimcode's separate build, so vimcode's own Cargo.toml needs a matching [patch.crates-io] entry pointing at the same vendored copy. Confirmed by quadraui#452's own commit message, which explicitly flagged this vimcode-side companion change as needed and out of scope for that session. With this, `cargo build --features gui` gets past dependency resolution (previously failed here with a unicode-width version conflict) — but still does not succeed end-to-end. It now hits a separate, unrelated, much larger issue: quadraui's `tui` feature currently pulls in ratatui 0.30 (bumped independently of #452 or #445, at some point between quadraui ebb4ab7 and current develop), which split Frame/Buffer/Rect into a new `ratatui-core` crate. vimcode's own TUI rendering code (src/tui_main/panels.rs, render_impl.rs, quadraui_tui.rs, mod.rs — ~46 call sites total) is still written directly against ratatui 0.29's types and is incompatible with quadraui's now-ratatui-core-based `Backend::enter_frame_scope` signature. That's a real, separate migration (bump vimcode's own ratatui pin and update every touched call site) — tracked separately, not attempted here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
JDonaghy
added a commit
that referenced
this pull request
Jul 20, 2026
The #587 regression (GTK global accelerators — Ctrl+Shift+P command palette, Ctrl+B sidebar, Ctrl+P quick-open — silently do nothing) has repeatedly slipped through Test-stage smoke as a build-against-stale- quadraui trap: quadraui#445's accelerator-dispatch fix is a behavioural change with no new public symbol, so a checkout that predates it still compiles vimcode cleanly and only fails at runtime. The vimcode side of #587 is already complete and correct on this branch (register_panel_accelerators wired into ShellApp::setup, UiEvent:: Accelerator handled in ShellApp::handle) — nothing there needed changing. The remaining failure mode was purely environmental: an artifact built against a quadraui checkout lacking #445. Add a build.rs guard that reads the sibling quadraui GTK key-controller source and hard-fails the build with actionable remediation if it does not call `match_keypress` (the Backend method #445 consults on the live key path). Converts the silent runtime breakage into a loud build error. Falls back to a warning (never a false failure) if the path dep points elsewhere. Verified: passes against quadraui develop tip (has #445); full lib suite green on both gui and default/TUI feature sets. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
JDonaghy
added a commit
that referenced
this pull request
Jul 20, 2026
…ndor quadraui#452 vendored vt100 0.16.2 with its unicode-width bound loosened (vendor/vt100-0.16.2-patched/) and patches it via [patch.crates-io] in quadraui's OWN Cargo.toml to resolve a conflict with ratatui 0.29's exact unicode-width=0.2.0 pin. But Cargo only honors [patch] sections declared in the root manifest of the workspace actually being built — quadraui's patch has zero effect on vimcode's separate build, so vimcode's own Cargo.toml needs a matching [patch.crates-io] entry pointing at the same vendored copy. Confirmed by quadraui#452's own commit message, which explicitly flagged this vimcode-side companion change as needed and out of scope for that session. With this, `cargo build --features gui` gets past dependency resolution (previously failed here with a unicode-width version conflict) — but still does not succeed end-to-end. It now hits a separate, unrelated, much larger issue: quadraui's `tui` feature currently pulls in ratatui 0.30 (bumped independently of #452 or #445, at some point between quadraui ebb4ab7 and current develop), which split Frame/Buffer/Rect into a new `ratatui-core` crate. vimcode's own TUI rendering code (src/tui_main/panels.rs, render_impl.rs, quadraui_tui.rs, mod.rs — ~46 call sites total) is still written directly against ratatui 0.29's types and is incompatible with quadraui's now-ratatui-core-based `Backend::enter_frame_scope` signature. That's a real, separate migration (bump vimcode's own ratatui pin and update every touched call site) — tracked separately, not attempted here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
JDonaghy
added a commit
that referenced
this pull request
Jul 20, 2026
The #587 regression (GTK global accelerators — Ctrl+Shift+P command palette, Ctrl+B sidebar, Ctrl+P quick-open — silently do nothing) has repeatedly slipped through Test-stage smoke as a build-against-stale- quadraui trap: quadraui#445's accelerator-dispatch fix is a behavioural change with no new public symbol, so a checkout that predates it still compiles vimcode cleanly and only fails at runtime. The vimcode side of #587 is already complete and correct on this branch (register_panel_accelerators wired into ShellApp::setup, UiEvent:: Accelerator handled in ShellApp::handle) — nothing there needed changing. The remaining failure mode was purely environmental: an artifact built against a quadraui checkout lacking #445. Add a build.rs guard that reads the sibling quadraui GTK key-controller source and hard-fails the build with actionable remediation if it does not call `match_keypress` (the Backend method #445 consults on the live key path). Converts the silent runtime breakage into a loud build error. Falls back to a warning (never a false failure) if the path dep points elsewhere. Verified: passes against quadraui develop tip (has #445); full lib suite green on both gui and default/TUI feature sets. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Both backends were inlining the same three steps after a content click on a non-split terminal pane:
```rust
engine.terminal_has_focus = true;
engine.terminal_scroll_reset();
if let Some(term) = engine.active_terminal_mut() {
term.selection = Some(TermSelection { ..click_cell });
}
```
Plus `handle_terminal_split_click` did the same work twice (once for `LeftPane`, once for `RightPane`) — its body literally repeated the three-step sequence after toggling `terminal_active`.
Extract `Engine::handle_terminal_pane_click(col, row)` as the single source of truth:
Net: `terminal_ops.rs` +3 / -3 (collapsed both arms), `tui_main/mouse.rs` -11 / -3.
Out of scope
GTK consumption (`src/gtk/mod.rs:6798-6811` has the same inline pattern) is a follow-up per the issue brief. Engine method is ready for GTK to consume in 1 line when that lands.
Test plan
Refs #429
🤖 Generated with Claude Code