bug: new-pane visibly flashes through an intermediate split before relayout #100

New issue

Closed

opened 2026-04-27 22:06:33 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-27 22:06:33 +00:00

Prerequisites

I have searched existing issues
I have updated to the latest version

tmux version

tmux 3.6a

Operating system

NixOS 26.05

Description

Reproduced on current main (9257228).

Explicit new-pane currently creates the pane with a generic tmux split first, then normalizes pane order, then reapplies the active layout. When the raw split geometry does not match the final semantic insertion slot, the user sees a visible transient flash/jump.

The clearest repro is master-stack with a single pane:

run new-pane
a bottom split appears briefly
Mosaic then relayouts the window and moves the new pane to the right as the first one-pane stack

This looks like a repo-wide behavior of the current new-pane pipeline, not just a master-stack quirk. All current layouts wire _layout_new_pane() to the shared append helper, so the path today is effectively:

tmux split-window
maybe bubble the pane to the semantic end of pane order
reapply the layout

So the visible glitch depends on how far the raw split is from the final layout, but the underlying non-atomic pipeline is universal.

This is especially obvious when:

the final layout wants a different axis than tmux's default raw split
the pane also needs to be moved through pane order before relayout
the layout relayout itself is multi-step (master-stack can issue more than one tmux layout mutation)

Expected

new-pane should be created directly in the final or closest-final semantic slot for the active layout, or at minimum avoid the obvious wrong-axis/wrong-side transient on common cases.

Steps to reproduce

Start tmux with only Mosaic loaded.
Set @mosaic-layout to master-stack.
In a single-pane window, run run-shell -b \"#{E:@mosaic-exec} new-pane\" (or bind it to a key).
Watch the geometry during creation.
The new pane flashes as a bottom split first, then is moved right by the final relayout.

Minimal tmux config

set -g base-index 1
set -g pane-base-index 1
run-shell /path/to/tmux-mosaic/mosaic.tmux
set-option -gwq @mosaic-layout master-stack
bind Enter run-shell -b '#{E:@mosaic-exec} new-pane'

Window layout snapshot

before: 200x50,0,0,0
after raw split: 200x50,0,0[200x25,0,0,0,200x24,0,26,1]
after final relayout: 200x50,0,0{99x50,0,0,0,100x50,100,0,1}

Additional context

This appears broader than the one-pane master-stack repro:

even when no bubble step is needed, the raw split can still be visually wrong until relayout lands
when a bubble step is needed, there is additional transient pane movement before the final layout
promote likely shares the same general class of issue because it also mutates pane order and then relayouts

So this seems worth tracking as a dedicated visual/creation-path bug rather than treating it as a layout-specific oddity.

## Prerequisites - [x] I have searched existing issues - [x] I have updated to the latest version ## tmux version ```text tmux 3.6a ``` ## Operating system NixOS 26.05 ## Description Reproduced on current `main` (`9257228`). Explicit `new-pane` currently creates the pane with a generic tmux split first, then normalizes pane order, then reapplies the active layout. When the raw split geometry does not match the final semantic insertion slot, the user sees a visible transient flash/jump. The clearest repro is `master-stack` with a single pane: - run `new-pane` - a bottom split appears briefly - Mosaic then relayouts the window and moves the new pane to the right as the first one-pane stack This looks like a repo-wide behavior of the current `new-pane` pipeline, not just a `master-stack` quirk. All current layouts wire `_layout_new_pane()` to the shared append helper, so the path today is effectively: 1. `tmux split-window` 2. maybe bubble the pane to the semantic end of pane order 3. reapply the layout So the visible glitch depends on how far the raw split is from the final layout, but the underlying non-atomic pipeline is universal. This is especially obvious when: - the final layout wants a different axis than tmux's default raw split - the pane also needs to be moved through pane order before relayout - the layout relayout itself is multi-step (`master-stack` can issue more than one tmux layout mutation) ### Expected `new-pane` should be created directly in the final or closest-final semantic slot for the active layout, or at minimum avoid the obvious wrong-axis/wrong-side transient on common cases. ## Steps to reproduce 1. Start tmux with only Mosaic loaded. 2. Set `@mosaic-layout` to `master-stack`. 3. In a single-pane window, run `run-shell -b \"#{E:@mosaic-exec} new-pane\"` (or bind it to a key). 4. Watch the geometry during creation. 5. The new pane flashes as a bottom split first, then is moved right by the final relayout. ## Minimal tmux config ```tmux set -g base-index 1 set -g pane-base-index 1 run-shell /path/to/tmux-mosaic/mosaic.tmux set-option -gwq @mosaic-layout master-stack bind Enter run-shell -b '#{E:@mosaic-exec} new-pane' ``` ## Window layout snapshot ```text before: 200x50,0,0,0 after raw split: 200x50,0,0[200x25,0,0,0,200x24,0,26,1] after final relayout: 200x50,0,0{99x50,0,0,0,100x50,100,0,1} ``` ## Additional context This appears broader than the one-pane `master-stack` repro: - even when no bubble step is needed, the raw split can still be visually wrong until relayout lands - when a bubble step is needed, there is additional transient pane movement before the final layout - `promote` likely shares the same general class of issue because it also mutates pane order and then relayouts So this seems worth tracking as a dedicated visual/creation-path bug rather than treating it as a layout-specific oddity.