feat: make even-vertical new-pane birth directly into the column tail #104

New issue

Closed

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

barrettruth commented

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

Problem

For even-vertical, the next pane always belongs at the column tail. Even though the column will still equalize afterward, explicit managed new-pane should not have to birth the pane in the wrong branch first.

Blocked by: #101, #102

Proposed solution

Make even-vertical target the semantic column tail directly during explicit managed new-pane. Accept full-column equalization afterward, but not a first-frame birth in the wrong branch.

Add or extend tests for:

1 -> 2, where the first frame should already be a top-to-bottom column
n >= 2, where the new pane should be born at the column tail before equalization

Context

This is one of the easy local-win layouts in the new-pane topology matrix. External precedent in the surveyed plugins is still mostly “split generically, then re-equalize,” but this case should be simpler than that.

Acceptance notes

1 -> 2 should not flash through a horizontal row.
For larger n, subsequent full-column equalization is acceptable.
Preserve append-order semantics.

Alternatives considered

Keep generic split then select-layout even-vertical.
Treat all resulting motion as harmless because the layout equalizes anyway.

## Problem For `even-vertical`, the next pane always belongs at the column tail. Even though the column will still equalize afterward, explicit managed `new-pane` should not have to birth the pane in the wrong branch first. Blocked by: #101, #102 ## Proposed solution Make `even-vertical` target the semantic column tail directly during explicit managed `new-pane`. Accept full-column equalization afterward, but not a first-frame birth in the wrong branch. Add or extend tests for: - `1 -> 2`, where the first frame should already be a top-to-bottom column - `n >= 2`, where the new pane should be born at the column tail before equalization ## Context This is one of the easy local-win layouts in the `new-pane` topology matrix. External precedent in the surveyed plugins is still mostly “split generically, then re-equalize,” but this case should be simpler than that. ## Acceptance notes - `1 -> 2` should not flash through a horizontal row. - For larger `n`, subsequent full-column equalization is acceptable. - Preserve append-order semantics. ## Alternatives considered - Keep generic split then `select-layout even-vertical`. - Treat all resulting motion as harmless because the layout equalizes anyway.