diff options
| author | user <user@clank> | 2026-09-29 14:26:28 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-09-29 14:26:28 +0200 |
| commit | ca1b5bdf5bf7b5ff01ab515846802b3487599d3a (patch) | |
| tree | a047fc09bccbe077b98acd0bf2648c2e02616b04 /docs/scripting.md | |
| parent | panes: read and write a pane by id, without taking focus (diff) | |
| download | slosh-ca1b5bdf5bf7b5ff01ab515846802b3487599d3a.tar.gz slosh-ca1b5bdf5bf7b5ff01ab515846802b3487599d3a.tar.xz slosh-ca1b5bdf5bf7b5ff01ab515846802b3487599d3a.zip | |
layouts, moves: build panes without pulling the view to them
Applying a layout landed on the first tab it made, and moving a pane into a
tab took focus there. For a program building a pane in the background that
is two failures at once: it yanks the view off the human mid-sentence, and
it leaves the *next* caller to read focus as "where I am" and put its work
in a stranger's tab.
`apply-layout focus:false` builds the tabs and keeps looking at whatever was
on screen; a layout naming an `active` tab still wins, because that is a
statement about where to be. `move-pane` gains `beside` (which pane in the
destination to split, rather than whatever it has focused) and `focus:false`
-- the two things a caller placing a pane next to *itself* needs.
That uncovered a sizing bug that was unreachable before: a pane's size comes
from a layout pass, and a tab nobody has looked at never had one, so a pane
built in the background stayed 1x1 and its program drew into a single cell.
The jump is what used to size it. layout_tab() gives a background tab a real
pass, borrowing the tab cursor for its length -- nothing composes, reads
input or draws a frame in between.
Diffstat (limited to 'docs/scripting.md')
0 files changed, 0 insertions, 0 deletions
