Owner idea from #411 live-testing: h and l as keyboard commands to shrink/grow the master
pane, complementing the divider's focused ArrowLeft/Right. Today keyboard resize requires reaching
the divider (Tab, or click-to-focus); h/l would make the ratio adjustable from anywhere, the
way j/k step the selection from anywhere.
Design considerations before implementing:
h/l complete the vim cluster next to j/k, which reads naturally as "left/right" — but in
vim-land they usually mean cursor movement, and here they'd mean layout movement; confirm
that reading is acceptable.
- Step size and floors should reuse the divider controller's math (
split.ts) and write through
the same single writer (prefs.applySplit), so the pref, the grid, and aria-valuenow can't
disagree.
- Interaction with reading mode: should
h past the floor snap into reading mode like the
divider's ArrowLeft does, and should l from reading mode restore the split?
- The keys are currently unbound outside typing targets, so no conflicts — but the help sheet and
the command palette should both surface them if added.
Owner idea from #411 live-testing:
handlas keyboard commands to shrink/grow the masterpane, complementing the divider's focused ArrowLeft/Right. Today keyboard resize requires reaching
the divider (Tab, or click-to-focus);
h/lwould make the ratio adjustable from anywhere, theway
j/kstep the selection from anywhere.Design considerations before implementing:
h/lcomplete the vim cluster next toj/k, which reads naturally as "left/right" — but invim-land they usually mean cursor movement, and here they'd mean layout movement; confirm
that reading is acceptable.
split.ts) and write throughthe same single writer (
prefs.applySplit), so the pref, the grid, andaria-valuenowcan'tdisagree.
hpast the floor snap into reading mode like thedivider's ArrowLeft does, and should
lfrom reading mode restore the split?the command palette should both surface them if added.