feat: make three-column birth the first side-column pane on the correct side #107

New issue

Closed

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

barrettruth commented

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

Problem

In the simplest three-column case (n = m = 1), the first side-column pane has an obvious semantic side. That pane should be born on the correct side first, with only local size correction afterward.

Blocked by: #101, #102

Proposed solution

Implement a layout-aware explicit new-pane path for the three-column 1 -> 2 transition (the default m = 1 case). The first frame should already place the new pane in the correct side column.

Keep later middle/right rebalancing transitions out of scope for this issue.

Context

This is the easy three-column case and should be separated from the harder cases where later stack parity changes force panes to cross between middle and right columns. Surveyed external plugins mostly accept full reprojection or explicit move-pane churn for comparable non-native multi-column layouts.

Acceptance notes

1 -> 2 should not flash through a wrong-branch birth.
Small width correction afterward is acceptable.
Preserve append-order semantics.

Alternatives considered

Accept full reprojection even for the trivial first side-column case.
Combine this with later three-column parity-transition work.

## Problem In the simplest `three-column` case (`n = m = 1`), the first side-column pane has an obvious semantic side. That pane should be born on the correct side first, with only local size correction afterward. Blocked by: #101, #102 ## Proposed solution Implement a layout-aware explicit `new-pane` path for the `three-column` `1 -> 2` transition (the default `m = 1` case). The first frame should already place the new pane in the correct side column. Keep later middle/right rebalancing transitions out of scope for this issue. ## Context This is the easy `three-column` case and should be separated from the harder cases where later stack parity changes force panes to cross between middle and right columns. Surveyed external plugins mostly accept full reprojection or explicit `move-pane` churn for comparable non-native multi-column layouts. ## Acceptance notes - `1 -> 2` should not flash through a wrong-branch birth. - Small width correction afterward is acceptable. - Preserve append-order semantics. ## Alternatives considered - Accept full reprojection even for the trivial first side-column case. - Combine this with later three-column parity-transition work.