| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bumpy one, again. Every `.py` outside `vendor/` plus the three `contrib/`
scripts that are Python with no extension: 60 files, 6,714 lines rewritten, no
behaviour changed. Nothing here is worth reading -- the next commit adds it to
`.git-blame-ignore-revs` so `git blame` walks past it.
It is a bigger reformat than the C was, 60% of the lines against 17%, and for a
reason worth writing down rather than tuning away: ruff and black break a call that
does not fit onto one argument per line, where this code aligned the continuation
under the opening paren. The test suite is thousands of `check("some prose", cond,
detail)` calls, so nearly every one of them changed shape and the suite grew 3,308
lines. Line length was the one lever that moved it -- 120 columns would have been a
40% reformat and no growth at all -- and it was left at 88, because picking an
unusual width to dodge a one-time diff is paying forever to avoid paying once.
Import sorting came with it. Two files had `import os, pty, uuid, select, struct,
sys, termios, time, fcntl, signal` on one line and now have ten.
Verified after, not before, because a formatter that alters behaviour would be
worse than none:
- `make retest`, 1801 checks green -- and this reformats the suite that does the
checking, including `harness.py`, which every one of those files imports.
- `make test-live`, the tty tests the fast suite skips. They matter here more than
usual: `live_input.py` and `live_m0.py` are two of the files whose comma-imports
were split, and nothing in the fast suite would have noticed if that broke them.
- All 60 files still compile, `make fmt` twice in a row changes nothing the second
time, and `ruff check --select I` has nothing left to say.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Half the crossings were invisible, and it was the half that depends on how you
built the layout rather than on how it looks.
Rows of columns gives a full-width row boundary with column boundaries running
into it from above and below. Columns of rows gives a full-height column
boundary with row boundaries running into it from the sides. On screen these
are the same picture; in the tree they are opposite, and the adjacency test
only looked for the first — two gaps touching side to side never matched, so a
layout built by splitting the other way round had no crossings at all.
The test is now that the two touch, in either axis. The crossing itself was
never in doubt: it is the column boundary's columns by the row boundary's rows,
which is the same cell either way.
Corners now hold up to two boundaries of each kind rather than two column ones
and a single row one. That asymmetry was an artefact of only ever having seen
the first nesting — in the second it is two row boundaries that can line up and
need to move together, for exactly the reason two column boundaries did.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resizing one row of a two-by-two puts its column boundary out of line with the
one below, which should leave two crossings on the row boundary, one for each.
Only one was found.
find_corners took the first column boundary it saw and then accepted others
only if they occupied exactly the same columns, which is the aligned case and
nothing else: anything out of line was discarded rather than becoming a
crossing of its own. It groups by the columns a boundary occupies now, so
aligned pairs are one crossing that moves both — still the case worth having,
since moving one of a matched pair would put a step in what reads as one line —
and everything else is its own crossing moving its own boundary.
The test starts aligned, moves one row's boundary, and checks the second
crossing appears and that dragging it leaves the other row alone.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Three faults in the corner drag, reported as glitches and picking panes up
along the way.
The drag held an index into the corner list, and that list is rebuilt from the
layout every frame — by a drag whose entire job is changing the layout. Move
the crossing and the corners are recomputed: the entry you grabbed can shift
position, or stop being a corner, and the index then names somebody else's
boundaries. That is exactly "it picks up additional panes and loses them
again", and it is the rule this codebase already states about the rect and the
collapsed flag, applied to something I stored anyway. The drag now carries the
boundaries themselves, so it moves what you grabbed until you let go, whatever
the layout does underneath. The test drags a deliberately misaligned grid in
circles and checks the boundary that was never part of the crossing is
untouched throughout.
The redraw was the dwell list again. Anything that arms after the pointer rests
has to be named in app_next_deadline_ms or it only appears when something else
happens to repaint — so it looked intermittent, which is the worst way for it
to be wrong. "corner:" is in the list now, next to the three that were already
there for the same reason.
And a crossing is two cells wide with nothing about it to suggest it is
anything, so it marks itself the moment the pointer arrives, before the dwell
that arms both boundaries. Passing over one costs a character; resting on one
still explains itself.
|
|
|
Where a boundary between rows crosses one between columns, that crossing is now
a handle: drag it and both move, following the pointer in x and y at once.
The two never overlap in the tree, which is the whole difficulty. A column
boundary belongs to a split inside one row and stops where the row boundary
begins; there is no cell that is part of both. So a corner is found by
adjacency instead — the cells of a row gap that have a column gap running into
them from above or below — and that has to be computed across splits rather
than within one, which is why it is a pass over the tree rather than something
draw_node could notice on its way past.
It moves every boundary that meets there, not one of them. In a two-by-two the
column boundary above the row and the one below are separate splits that happen
to line up, and moving only the one you were nearest would leave a step in what
reads as a single line. Both get the same delta.
The corner's hit is registered after the two gap hits it sits on, so those
cells resolve to the corner rather than to whichever gap drew last: it is one
target, not an overlap. Resting on it arms *both* boundaries rather than
lighting the cell under the pointer, because the hint is supposed to show what
is about to move.
Finding the corners needed the gap rectangle, which draw_node had been working
out inline. It is one function now, shared by the drawing, the hit and the
corner search — three things that have to agree about where a gap is down to
the cell, and would not have for long.
|
