feat: reduce wrong-branch new-pane births in master-stack when a stack already exists #105

New issue

Closed

opened 2026-04-28 01:57:48 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-28 01:57:48 +00:00

Problem

In master-stack when n > m, the stack already exists and the next pane semantically belongs at the stack tail. In that state, splitting the master first and then visibly moving or reprojecting the new pane across the window is unnecessary churn.

Blocked by: #101, #102

Proposed solution

Make explicit managed new-pane target the existing stack tail directly for all master-stack orientations when n > m.

Scope:

in scope: stack already exists (n > m)
out of scope: all-masters transition (n = m)
out of scope: mirrored 1 -> 2 policy conflict for m = 1

Tests should show that the master region does not get split first when the operation is just appending to an existing stack.

Context

This is the highest-value local master-stack fix after #100. Surveyed plugins show both sides of the design space:

tmux-layouts births in the right broad direction for its simple master/stack analog
tmux-tiler targets the existing stack branch once the stack exists
dwm.tmux and awesomewm.tmux accept split -> swap -> relayout churn

Acceptance notes

The first frame should already be in the stack branch.
Local stack equalization or mfact correction afterward is acceptable.
Preserve append-to-end pane order.

Alternatives considered

Keep generic split -> relayout behavior.
Fix only one orientation and leave the others inconsistent.

## Problem In `master-stack` when `n > m`, the stack already exists and the next pane semantically belongs at the stack tail. In that state, splitting the master first and then visibly moving or reprojecting the new pane across the window is unnecessary churn. Blocked by: #101, #102 ## Proposed solution Make explicit managed `new-pane` target the existing stack tail directly for all `master-stack` orientations when `n > m`. Scope: - in scope: stack already exists (`n > m`) - out of scope: all-masters transition (`n = m`) - out of scope: mirrored `1 -> 2` policy conflict for `m = 1` Tests should show that the master region does not get split first when the operation is just appending to an existing stack. ## Context This is the highest-value local `master-stack` fix after #100. Surveyed plugins show both sides of the design space: - `tmux-layouts` births in the right broad direction for its simple master/stack analog - `tmux-tiler` targets the existing stack branch once the stack exists - `dwm.tmux` and `awesomewm.tmux` accept split -> swap -> relayout churn ## Acceptance notes - The first frame should already be in the stack branch. - Local stack equalization or mfact correction afterward is acceptable. - Preserve append-to-end pane order. ## Alternatives considered - Keep generic split -> relayout behavior. - Fix only one orientation and leave the others inconsistent.