feat: drag panes to move/swap, plus a clearer tab-drag affordance

[GeneralD]

Part of #77 (mouse-interaction tracking).

Motivation

The minimap already supports point interactions — click a pane to focus it (#74), click a tab to switch (#8), scroll to walk tabs/panes (#80), and drag a tab block to reorder it (#10). The natural next step is drag-to-move: grab a pane in the minimap and drop it where you want, the same way you'd rearrange windows in a tiling WM — directly and spatially, without memorizing a keybind chord.

Proposal

Roughly in order of ambition:

1. Drag a pane to move/swap it within its tab

Press on a minimap pane cell, drag, release on another pane cell → move/swap those panes within the tab's layout. This builds directly on the position→pane hit-test from #74 (minimap::pane_at_cell, TabPaneGeom) and the grab/hold/release state machine from #10 (DragState, grab_at / mark_dragging / commit_drag_at).

Open question: zellij's pane-move primitives are direction-based (MovePane, MovePaneBackwards), not "swap pane A with pane B". We need to verify whether an arbitrary drop target can be reached deterministically by emitting a sequence of directional moves, or whether a swap-/move-by-id API is usable from a plugin. Like reorder, this needs RunActionsAsUser (already gated behind the reorder flag, #23).

2. Drag a pane across tabs

Drop a pane onto a different tab's block → move the pane out of its current tab into the target. Conceptually adjacent to #80's "pane mode walks across tab boundaries". zellij has break-pane / move-pane-to-tab style actions to investigate (BreakPane*).

3. Tab-reorder vs pane-drag — disambiguate the gesture (UI under discussion)

Today any drag on a tab block reorders the tab (#10). Once pane cells become draggable, that gesture is overloaded: does dragging inside a tab mean "move this pane" or "reorder this tab"? We want to keep drag-to-reorder for tabs but give it a dedicated affordance so the two never collide. Two candidates:

• (a) Top-row grab — dragging the tab's top row (the title/header strip, above the pane minimap) reorders the tab; dragging a pane cell moves the pane.
• (b) Drag-handle icon — a small grip glyph placed next to the close button (mouse: an 'x' close button on each tab block (click hit-test) #86), grabbed explicitly for tab reordering.

Note

This is the main open design question. Sketch of the trade-offs:

• (a) costs no horizontal space and is discoverable ("grab the header"), but the top row is thin (1 cell), so the hit target is small, and it competes with the close button / any future header controls.
• (b) is explicit and unambiguous, but consumes a column per tab and couples to mouse: an 'x' close button on each tab block (click hit-test) #86's close-button layout.

4. (Stretch) animation-like feedback during drag

A plugin only repaints on events and zellij pushes no frame clock, so true tweened animation isn't really on the table. But cheap "animation-ish" cues are: lift/shadow the grabbed pane (reuse the perspective depth effect from #66), highlight the drop target, or slide the insertion gap. Lowest priority — explicitly optional.

Relevant Code

• src/lib.rs:188-217 — the LeftClick / Hold / Release arms and DragState (tab reorder, v2: drag-and-drop tab reordering #10)
• src/lib.rs:377 focus_or_switch_at + src/minimap.rs:80 pane_at_cell — the position→pane hit-test (mouse: click a minimap pane to focus it (position -> pane hit-test) #74)
• src/lib.rs:569 reorder — the RunActionsAsUser action-dispatch pattern to mirror for pane moves
• src/tab_block.rs, src/paint.rs — where a drag-handle / top-row affordance would be drawn

Notes

• Builds on mouse: click a minimap pane to focus it (position -> pane hit-test) #74 (pane hit-test) and v2: drag-and-drop tab reordering #10 (drag state machine); reorder gating in feat(config): gate RunActionsAsUser behind a reorder flag (default off) so auto-updaters don't freeze #23, perspective effect in Perspective mode: variable bar height that lifts the active tab #66, pane-mode tab crossing in mouse: scroll the tab bar to switch tabs or walk panes (tab/pane modes) #80.
• §1–3 are one coherent "drag-to-move" unit sharing the gesture-disambiguation problem; §4 (animation) is bundled here as a stretch goal and can spin out into its own issue if it grows.

[GeneralD]

This feature's drag premise is blocked by #102 (confirmed from the zellij-server 0.44.3 source).

The tab bar pins itself non-selectable (set_selectable(false)), so it is never the active pane, and zellij's mouse router (determine_mouse_action, tab/mouse_handler.rs:1399-1414) only forwards a left Motion (Mouse::Hold) or Release to the active pane. The bar therefore receives the initial LeftClick (focus path → PluginPane::start_selection → Mouse::LeftClick) but never the Hold/Release a drag needs. The plugin sees exactly one event per drag gesture — the press — so it cannot even reconstruct a drag.

Since "drag panes to move/swap" rides the same DragState / Hold mechanism as tab reorder (#10), it is blocked identically. There is no plugin-side fix as a drag, and 0.44.3 is the latest released zellij, so no version bump lifts the limitation.

Viable path: discrete LeftClick still works (switch #8, focus-pane #74, close #86, new-tab #76), so a move/swap built on clicks — move arrows on the active tab, or a click-to-grab → click-to-drop mode — is implementable today. A drag affordance only becomes worth designing if zellij changes this routing upstream.