refactor(orzmux): make a tab's layout tree non-empty by type - #389
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
not-elm
added this pull request to stack #391
October 1, 2026 07:20
Move the inline `tests` module of `backend/layout.rs` to `backend/layout/tests.rs`, which keeps the shared fixtures, and to one file each for `split`, `remove`, `solve`, `select_direction`, `resize_split`, and `resize_direction`. The tests themselves are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nothing here solves constraints: the method folds minimum sizes and subdivides the window top-down. Call it `tile`, returning `Tiling`, with `Node::tile_into` underneath, and move the tests to `tests/tile.rs`. `OrzmuxError::Unsolved` becomes `NoPaneRect`. The computation cannot fail; the variant reports that the new pane has no rectangle because its tab is gone or the tab's tree does not hold it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
`LayoutTree::split` took the window size only to refuse a target too small to divide, although the tree stores ratios and a tree split past its room is still a valid tree. The room is a policy applied when a pane is split, so it moves to the caller: `Tiling::can_split` answers whether a pane's rectangle holds two minimum leaves and a separator, and `Tabs::split_active` asks it before splitting. `split` no longer takes a window and reports a missing target as `UnresolvedTarget`, leaving `SplitRefused` to mean too little room. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A
LayoutTreecould be empty (root: Option<Node>,active() -> Option<PaneId>).retire_paneemptied the tree and removed the tab a few lines later, so "a tab has a pane" held only by call order.Solution
orzmux::backend, with no change in behavior:LayoutTreeis built only bywith_rootand always holds a pane:rootis aNode,active()returns aPaneId, andDefaultandis_empty()are gone.remove(self, pane)hands the tree back asAbsent,Removed, orLast; removing the only pane leaves the tree unchanged.Tabs::remove_panedrops the whole tab onLast.retire_paneand the rollback of a failed spawn both go through it.LayoutTree::solveis renamed totile, returningTiling, andOrzmuxError::UnsolvedtoNoPaneRect: the method subdivides the window and cannot fail, and the error reports a pane with no rectangle.LayoutTree::splitno longer takes the window size. Whether the target has room is a policy of the moment, soTabs::split_activeasks the newTiling::can_splitbefore splitting. A missing target isUnresolvedTarget;SplitRefusednow means only too little room.layout.rstolayout/tests/, one file per operation.🤖 Generated with Claude Code