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 /src/app.h | |
| 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 'src/app.h')
0 files changed, 0 insertions, 0 deletions
