feat: add shared primitives for layout-aware managed new-pane targeting #102

New issue

Closed

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

barrettruth commented

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

Problem

Follow-up work from #100 needs a reusable way to choose the semantic split target, split axis, split side, cwd preservation, focus preservation, and minimal reorder behavior for managed explicit new-pane. Right now those concerns are either generic or layout-local, which makes the hard cases easy to re-solve badly.

Blocked by: #101

Proposed solution

Add shared primitives for layout-aware managed new-pane creation. The shared layer should make it possible for layouts to say, in effect:

target this existing pane or semantic tail
split on this axis and side
preserve current cwd and expected focus
perform the smallest possible post-split order correction when order really matters

Keep layout-specific policy out of the shared layer. The purpose of this issue is to make later layout issues smaller and more consistent.

Context

This issue is the common engineering substrate for the layout-by-layout fixes being spun out of #100.

Acceptance notes

Preserve the documented append-to-end pane-order contract unless a later policy issue explicitly changes it.
Avoid baking layout-specific topology into the shared helpers.
Make the API clean enough that master/column, recursive, and equalization layouts can all use it.

Alternatives considered

Implement every layout independently. That duplicates split targeting and reorder logic in many places.
Keep the current generic split-first path everywhere and only relayout afterward.

## Problem Follow-up work from #100 needs a reusable way to choose the semantic split target, split axis, split side, cwd preservation, focus preservation, and minimal reorder behavior for managed explicit `new-pane`. Right now those concerns are either generic or layout-local, which makes the hard cases easy to re-solve badly. Blocked by: #101 ## Proposed solution Add shared primitives for layout-aware managed `new-pane` creation. The shared layer should make it possible for layouts to say, in effect: - target this existing pane or semantic tail - split on this axis and side - preserve current cwd and expected focus - perform the smallest possible post-split order correction when order really matters Keep layout-specific policy out of the shared layer. The purpose of this issue is to make later layout issues smaller and more consistent. ## Context This issue is the common engineering substrate for the layout-by-layout fixes being spun out of #100. ## Acceptance notes - Preserve the documented append-to-end pane-order contract unless a later policy issue explicitly changes it. - Avoid baking layout-specific topology into the shared helpers. - Make the API clean enough that master/column, recursive, and equalization layouts can all use it. ## Alternatives considered - Implement every layout independently. That duplicates split targeting and reorder logic in many places. - Keep the current generic split-first path everywhere and only relayout afterward.