aboutsummaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authoruser <user@clank>2026-08-16 20:34:29 +0200
committeruser <user@clank>2026-08-16 20:34:29 +0200
commit967d8521c2b021457f33bf87ef762100a5e2a74c (patch)
treee1d0d4b7214e2595c37d06d70d4590cfaf6e26af /docs
parentsl0ppty: layouts are `*.layout.kdl`, and each loader says which it got (diff)
downloadslosh-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.md5
-rw-r--r--docs/panes.md13
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