diff options
| author | user <user@clank> | 2026-08-16 20:34:29 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-16 20:34:29 +0200 |
| commit | 967d8521c2b021457f33bf87ef762100a5e2a74c (patch) | |
| tree | e1d0d4b7214e2595c37d06d70d4590cfaf6e26af /docs | |
| parent | sl0ppty: layouts are `*.layout.kdl`, and each loader says which it got (diff) | |
| download | slosh-967d8521c2b021457f33bf87ef762100a5e2a74c.tar.gz slosh-967d8521c2b021457f33bf87ef762100a5e2a74c.tar.xz slosh-967d8521c2b021457f33bf87ef762100a5e2a74c.zip | |
sl0ppty: `C-a Enter` splits the longer way
One key for "I want a pane and I have no opinion about where". It cuts across the
pane's longer side, so the two halves come out as square as the pane allows, and
pressing it four times on a 100x30 terminal tiles the tab the way you would have
done it by hand: a column, then rows inside the new column, then rows again, then
a word saying there is no room left.
"Longer" is a question about what you can *see*. A cell is about twice as tall as
it is wide, so 80x24 is a wide pane (80 against 48) while 40x24 is not (40 against
48). `gap_aspect` is already this program's answer to how many columns a row is
worth, so that is the number used rather than a second constant meaning the same
thing -- and a config that says cells are square gets a square answer. There is a
test at 74x44, the size where the two readings disagree: square cells split it into
columns, the default splits it into rows.
The fallback is the other half of "sensible". A pane that is wide but ten rows tall
wants cutting across; if `split_fits` says that will not fit, the other axis is
tried before giving up. And it says which way it went -- `split right` or `split
down`, the same two words the border click already uses -- because one key that can
do two things has to tell you which it did.
**`split_fits` had a hole this action made obvious.** It only ever asked about the
dimension being divided, so a pane four rows tall on a short terminal "had room" for
two columns: the width was fine, and the two panes it produced were immediately
collapsed into a list by the layout. The border was offering that, and both split
keys were doing it. It now also requires the axis it does *not* divide to clear the
floor, because splitting cannot improve that one -- the same hole `layout_node`
closed at the leaf, one level up. On a 100x8 terminal all three now say "no room to
split" instead of undoing the arrangement.
Verified: nine checks in `tests/test_split_ux.py` -- the axis chosen for wide and
for tall panes, the aspect deciding at 74x44, both fallback directions, the refusal
and that the explicit keys refuse the same way, and that it appears on the
cheatsheet under `enter` and in the palette by name. The existing 65 checks about
what the border offers still pass, which is what I was most worried about.
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/keys.md | 5 | ||||
| -rw-r--r-- | docs/panes.md | 13 |
2 files changed, 13 insertions, 5 deletions
diff --git a/docs/keys.md b/docs/keys.md index 648568a..47c419b 100644 --- a/docs/keys.md +++ b/docs/keys.md @@ -14,7 +14,8 @@ it did not — `+7 more, in docs/keys.md`, which is the table below. | key | does | |---|---| -| `\` `-` | split into columns / rows | +| `Enter` | split whichever way there is more room — across the longer side, and the other axis if that will not fit | +| `\` `-` | split into columns / rows, when you mean one | | `h` `j` `k` `l`, or arrows | move focus | | `o` | the next pane | | `H` `J` `K` `L`, or shift+arrows | move the boundary between panes | @@ -100,7 +101,7 @@ being bound at all. | group | actions | |---|---| -| panes | `split-cols` `split-rows` `close-pane` `rerun` `zoom` `minimize` `rotate-layout` `clear-shaders` `pane-to-next-tab` `pane-to-prev-tab` `pane-to-new-tab` | +| panes | `split` `split-cols` `split-rows` `close-pane` `rerun` `zoom` `minimize` `rotate-layout` `clear-shaders` `pane-to-next-tab` `pane-to-prev-tab` `pane-to-new-tab` | | focus | `focus-left` `focus-right` `focus-up` `focus-down` `focus-next` `finder` | | size | `resize-left` `resize-right` `resize-up` `resize-down` `equalize` | | tabs | `new-tab` `next-tab` `prev-tab` `select-tab-1` … `select-tab-9` | diff --git a/docs/panes.md b/docs/panes.md index 95bcdc5..f6f9297 100644 --- a/docs/panes.md +++ b/docs/panes.md @@ -5,8 +5,12 @@ looking at is drawn. ## Arranging -- **Split** with `C-a \` and `C-a -`. Splitting the same direction again gives - three equal shares rather than 1/2 + 1/4 + 1/4. +- **Split** with `C-a Enter` and it picks the axis: across the pane's longer side, + measured as you see it (a cell is about twice as tall as it is wide, which is + what `gap_aspect` says), falling back to the other axis when that one will not + fit and saying which way it went. `C-a \` and `C-a -` when you mean one. + Splitting the same direction again gives three equal shares rather than + 1/2 + 1/4 + 1/4. - **Resize** with `C-a H J K L`: the boundary moves the way you press, whichever side of it you are on. Sizes are *weights*, so a resized layout survives the window changing size. @@ -81,7 +85,10 @@ recomputed from the tree every frame, and the list is what that function returns when the room runs out. `min_pane` is where that starts happening; `min_split` is the smaller pane a -split is willing to *create*. +split is willing to *create*. A split is refused when either floor would be +broken — including the axis it does not divide, since splitting cannot improve +that one: a pane already too short for two rows has no room for two columns +either, whatever its width says. ## Text, images, bells |
