feat(algorithm): deck #45

New issue

Closed

opened 2026-04-26 00:36:55 +00:00 by barrettruth · 1 comment

barrettruth commented

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

Add a deck algorithm — one visible master pane plus a stacked "deck" area where only one stack pane is visible at a time. This is a classic dwm layout and a strong terminal fit.

Scope

New file scripts/algorithms/deck.sh
One master region remains visible
Non-master panes occupy a deck area rather than equal-split stack slots
promote and resize-master should work like master-stack
Decide how stack focus cycles inside the deck area

Acceptance criteria

Setting @mosaic-algorithm deck applies master + deck behavior
Only one stack pane is visible at a time
promote swaps the focused stack pane into master
resize-master ±N resizes master and persists in @mosaic-mfact
Tests cover split, kill, focus change, and promote flows
README documents the behavior difference from master-stack and monocle

Implementation notes

Conceptually this is "master + monocle stack".

Part of #42.

Add a `deck` algorithm — one visible master pane plus a stacked "deck" area where only one stack pane is visible at a time. This is a classic dwm layout and a strong terminal fit. ## Scope - New file `scripts/algorithms/deck.sh` - One master region remains visible - Non-master panes occupy a deck area rather than equal-split stack slots - `promote` and `resize-master` should work like master-stack - Decide how stack focus cycles inside the deck area ## Acceptance criteria - [ ] Setting `@mosaic-algorithm deck` applies master + deck behavior - [ ] Only one stack pane is visible at a time - [ ] `promote` swaps the focused stack pane into master - [ ] `resize-master ±N` resizes master and persists in `@mosaic-mfact` - [ ] Tests cover split, kill, focus change, and promote flows - [ ] README documents the behavior difference from `master-stack` and `monocle` ## Implementation notes Conceptually this is "master + monocle stack". Part of #42.

barrettruth commented

2026-04-26 02:31:54 +00:00

Closing this as out of scope for tmux.

Canonical deck semantics are clear from dwm: it supports nmaster, keeps the master area visible, and places every non-master client into the same stack rectangle so the focused stack client is the one visible on top.

That does not map cleanly to tmux. tmux pane layouts are non-overlapping split trees, and window zoom hides everything except the active pane, so there is no faithful way to keep the master area visible while also making the stack behave like a true overlapping deck.

A tmux-specific approximation could be discussed separately later, but a real deck layout is not representable here without changing the contract.

Closing this as out of scope for tmux. Canonical `deck` semantics are clear from dwm: it supports `nmaster`, keeps the master area visible, and places every non-master client into the same stack rectangle so the focused stack client is the one visible on top. That does not map cleanly to tmux. tmux pane layouts are non-overlapping split trees, and window zoom hides everything except the active pane, so there is no faithful way to keep the master area visible while also making the stack behave like a true overlapping deck. A tmux-specific approximation could be discussed separately later, but a real `deck` layout is not representable here without changing the contract.