feat(algorithm): two-pane #47

New issue

Closed

opened 2026-04-26 00:36:57 +00:00 by barrettruth · 2 comments

barrettruth commented

2026-04-26 00:36:57 +00:00

Add a two-pane algorithm — always show the master pane plus one secondary pane. This fits small tmux workspaces and the XMonad TwoPane mental model.

Scope

New file scripts/algorithms/two-pane.sh
One pane is master
Second visible pane is either the focused non-master pane or the next pane in order
Remaining panes need a clear rule: hidden/stacked/ignored until focused
promote and resize-master should still work

Acceptance criteria

Setting @mosaic-algorithm two-pane shows only two panes at a time
promote swaps the secondary pane into master
resize-master ±N resizes the master split
Focusing another pane replaces the visible secondary pane
Tests cover 2-pane and 3+ pane cases
README documents semantics clearly

Open question

Should this be "master + focused secondary", or "first two panes only" until explicitly rotated?

Part of #42.

Add a `two-pane` algorithm — always show the master pane plus one secondary pane. This fits small tmux workspaces and the XMonad `TwoPane` mental model. ## Scope - New file `scripts/algorithms/two-pane.sh` - One pane is master - Second visible pane is either the focused non-master pane or the next pane in order - Remaining panes need a clear rule: hidden/stacked/ignored until focused - `promote` and `resize-master` should still work ## Acceptance criteria - [ ] Setting `@mosaic-algorithm two-pane` shows only two panes at a time - [ ] `promote` swaps the secondary pane into master - [ ] `resize-master ±N` resizes the master split - [ ] Focusing another pane replaces the visible secondary pane - [ ] Tests cover 2-pane and 3+ pane cases - [ ] README documents semantics clearly ## Open question Should this be "master + focused secondary", or "first two panes only" until explicitly rotated? Part of #42.

barrettruth commented

2026-04-26 02:33:24 +00:00

I checked the real XMonad TwoPane semantics before we build this.

Canonical TwoPane is not just "a small split layout"; it really does show only two windows: the master on the left, and on the right either the focused window or the second window in layout order. Extra windows are not laid out.

That puts this in the same problem class as deck for tmux: tmux pane layouts are non-overlapping split trees, so there is no faithful way to keep exactly two panes visible while other panes in the same window remain hidden but still focusable in the background.

So this issue probably needs one of two outcomes before implementation:

close it as out of scope for a faithful tmux port, or
rewrite it explicitly as a tmux-specific approximation with a narrower contract

I would not implement this as-is without deciding that first.

I checked the real XMonad `TwoPane` semantics before we build this. Canonical `TwoPane` is not just "a small split layout"; it really does show only two windows: the master on the left, and on the right either the focused window or the second window in layout order. Extra windows are not laid out. That puts this in the same problem class as `deck` for tmux: tmux pane layouts are non-overlapping split trees, so there is no faithful way to keep exactly two panes visible while other panes in the same window remain hidden but still focusable in the background. So this issue probably needs one of two outcomes before implementation: - close it as out of scope for a faithful tmux port, or - rewrite it explicitly as a tmux-specific approximation with a narrower contract I would not implement this as-is without deciding that first.

barrettruth commented

2026-04-26 03:32:26 +00:00

I re-checked the real XMonad TwoPane behavior before implementing this. Canonical TwoPane shows only two windows at a time: the master on the left, and on the right either the focused window or the second window in layout order. Extra windows stay in the workspace but are not laid out.

That hidden-window model does not map cleanly to tmux panes inside one window, which are represented as one visible non-overlapping split tree. So this lands in the same mismatch class as deck: there is no faithful tmux-native way to keep exactly two panes visible while other panes in the same window remain hidden but still focusable in the background.

Given that mismatch, and because existing tmux-native layouts already cover the practical small-workspace cases better, I’m closing this as not planned rather than adding an ambiguous approximation.

I re-checked the real XMonad `TwoPane` behavior before implementing this. Canonical `TwoPane` shows only two windows at a time: the master on the left, and on the right either the focused window or the second window in layout order. Extra windows stay in the workspace but are not laid out. That hidden-window model does not map cleanly to tmux panes inside one window, which are represented as one visible non-overlapping split tree. So this lands in the same mismatch class as `deck`: there is no faithful tmux-native way to keep exactly two panes visible while other panes in the same window remain hidden but still focusable in the background. Given that mismatch, and because existing tmux-native layouts already cover the practical small-workspace cases better, I’m closing this as not planned rather than adding an ambiguous approximation.