feat: register Rename Active Pane as a keyboard-bindable action (#9351)#9712
feat: register Rename Active Pane as a keyboard-bindable action (#9351)#9712lonexreb wants to merge 1 commit intowarpdotdev:masterfrom
Conversation
…dotdev#9351) The Rename Pane action shipped only via the right-click context menu on a pane title bar (`WorkspaceAction::RenamePane(PaneViewLocator)`). Because the variant requires an explicit locator, it can't be wired into the keybinding registry, the Command Palette, or Settings → Keyboard shortcuts — keyboard-driven users had no path to the action. Mirror the existing RenameActiveTab pattern: - `app/src/workspace/action.rs`: add a parameterless `RenameActivePane` variant alongside `RenameActiveTab`. Add it to `should_save_app_state_on_action`, since the underlying `rename_pane` mutates `pane_configuration`. - `app/src/workspace/view.rs`: handle the new variant by resolving the active tab's pane group, looking up its focused pane id, and delegating to the existing `rename_pane(locator, ctx)` path. Zero new render or persistence code. - `app/src/workspace/mod.rs`: register `workspace:rename_active_pane` ("Rename the current pane") as an EditableBinding under the Settings group, with no default keystroke so users see it in Settings → Keyboard shortcuts and can bind it. Scope is intentionally limited to the keyboard-binding surface — the issue's three asks are (1) the binding registry, (2) the Command Palette, (3) an optional `/rename-pane` slash command. (1) is the reporter's primary concern; (2) and (3) are follow-ups. A unit test in `action_tests.rs` confirms the new variant participates in `should_save_app_state_on_action`, parallel to the existing `RenamePane(locator)` coverage. I have not exercised the binding through Settings → Keyboard shortcuts locally — this checkout cannot run Warp (no Metal toolchain in the build environment). CI lanes (MacOS/Linux/Windows) will validate compilation; a maintainer with a working dev build can verify the new binding shows up in Settings as expected.
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I reviewed this pull request and requested human review from: @warpdotdev/oss-maintainers. Comment Powered by Oz |
There was a problem hiding this comment.
Overview
This PR adds a parameterless RenameActivePane workspace action, registers it as an editable binding, dispatches it by resolving the focused pane in the active tab, and extends the persistence test coverage for pane rename actions.
Concerns
- No blocking correctness, security, or error-handling concerns found in the changed hunks.
Verdict
Found: 0 critical, 0 important, 0 suggestions
Approve
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
|
Thanks @alokedesai for the approval! Whenever a maintainer has a moment to merge this in, I'd appreciate it. Happy to rebase if anything goes stale. 🙏 |
Description
Resolves the keyboard-binding portion of #9351.
The Rename Pane action shipped only via the right-click context menu on a pane title bar (`WorkspaceAction::RenamePane(PaneViewLocator)`). Because that variant requires an explicit locator, it can't be wired into the keybinding registry, the Command Palette, or Settings → Keyboard shortcuts — keyboard-driven users had no path to the action.
This PR mirrors the existing `RenameActiveTab` pattern by adding a parameterless `RenameActivePane` variant that resolves the active pane at dispatch time and delegates to the existing `rename_pane` infrastructure.
Linked Issue
Resolves #9351 (binding-registry portion).
Changes
Scope
The issue's three asks are:
(2) and (3) can be follow-ups once (1) lands; keeps the PR atomic.
Testing
Once verified, follow-up keysets-manifest registration in warpdotdev/keysets (out of scope for this repo) would let the action also surface as a default-keyset entry.
Agent Mode
CHANGELOG-IMPROVEMENT: Rename Pane is now reachable from Settings → Keyboard shortcuts as a remappable binding (`workspace:rename_active_pane`), in addition to the existing right-click context menu. Thanks @lonexreb!