feat: reduce master-stack all-masters-to-stack transition churn when nmaster > 1 #112

New issue

Closed

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

barrettruth commented

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

Problem

In master-stack when n = m > 1, explicit new-pane transitions the window from an all-masters state into master-plus-stack. There is no existing stack tail to target, so this is a harder topology change than ordinary stack-tail append.

Blocked by: #101, #102, #105

Proposed solution

Investigate whether the first stack pane in the n = m > 1 case can still be born into the correct broad branch with less visible churn, while preserving master semantics and append order.

This issue should focus only on n = m > 1. Keep the mirrored m = 1, 1 -> 2 policy conflict out of scope.

Context

The current matrix classifies this as a global-reshape case. Surveyed external plugins usually accept relayout and sometimes explicit swap/move churn in this family rather than solving it at birth.

Acceptance notes

Reduce avoidable wrong-branch birth if possible.
If some churn is fundamentally tied to the topology change, make that explicit and testable.
Do not regress the easier n > m stack-tail cases.

Alternatives considered

Keep the current generic split-first behavior.
Merge this with the easier master-stack stack-tail issue, making the scope too mixed.

## Problem In `master-stack` when `n = m > 1`, explicit `new-pane` transitions the window from an all-masters state into master-plus-stack. There is no existing stack tail to target, so this is a harder topology change than ordinary stack-tail append. Blocked by: #101, #102, #105 ## Proposed solution Investigate whether the first stack pane in the `n = m > 1` case can still be born into the correct broad branch with less visible churn, while preserving master semantics and append order. This issue should focus only on `n = m > 1`. Keep the mirrored `m = 1`, `1 -> 2` policy conflict out of scope. ## Context The current matrix classifies this as a global-reshape case. Surveyed external plugins usually accept relayout and sometimes explicit swap/move churn in this family rather than solving it at birth. ## Acceptance notes - Reduce avoidable wrong-branch birth if possible. - If some churn is fundamentally tied to the topology change, make that explicit and testable. - Do not regress the easier `n > m` stack-tail cases. ## Alternatives considered - Keep the current generic split-first behavior. - Merge this with the easier `master-stack` stack-tail issue, making the scope too mixed.