feat: define monocle new-pane zoom and focus behavior #116

New issue

Closed

opened 2026-04-28 01:58:03 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-28 01:58:03 +00:00

Problem

monocle is not mainly a branch-placement problem. It is a zoom/focus behavior problem. The repo needs an explicit policy for what should happen during explicit managed new-pane when monocle is active or needs to be reasserted.

Blocked by: #101

Proposed solution

Define and implement monocle new-pane behavior around:

whether zoom should remain visually continuous
whether intermediate structural churn may happen under the hood if it stays hidden
which pane should end up focused after creation
how relayout and zoom reassertion interact

Context

Surveyed external plugins split in two directions:

dwm.tmux re-applies its tiled layout and then re-zooms
tmux-tiling-revamped largely lets zoom stand and does not reapply monocle on split hooks

Acceptance notes

End with a clear policy and tests for focus/zoom expectations.
Treat this as a monocle-specific visual contract, not as a generic spatial-layout issue.
Feed any remaining residual snap into the final documentation issue.

Alternatives considered

Treat monocle as if it were a normal spatial layout.
Ignore the zoom/focus snap because “the pane is fullscreen anyway.”

## Problem `monocle` is not mainly a branch-placement problem. It is a zoom/focus behavior problem. The repo needs an explicit policy for what should happen during explicit managed `new-pane` when monocle is active or needs to be reasserted. Blocked by: #101 ## Proposed solution Define and implement `monocle` `new-pane` behavior around: - whether zoom should remain visually continuous - whether intermediate structural churn may happen under the hood if it stays hidden - which pane should end up focused after creation - how relayout and zoom reassertion interact ## Context Surveyed external plugins split in two directions: - `dwm.tmux` re-applies its tiled layout and then re-zooms - `tmux-tiling-revamped` largely lets zoom stand and does not reapply `monocle` on split hooks ## Acceptance notes - End with a clear policy and tests for focus/zoom expectations. - Treat this as a monocle-specific visual contract, not as a generic spatial-layout issue. - Feed any remaining residual snap into the final documentation issue. ## Alternatives considered - Treat monocle as if it were a normal spatial layout. - Ignore the zoom/focus snap because “the pane is fullscreen anyway.”