One direction to drop in, and a new note that stays on top

Every new note pulled the arrangement apart. A note was made with no
position and left to the tie-break, which put it near the top by age --
which is not the same thing. A separator's position counts the rows above
it, so a row appearing without a renumber left every line one row too
high. placeOnTop builds the order from the list *without* the new note and
puts it in front: measuring the room after the furniture has moved would
write the misreading back as the truth.

A drop now lands the row under the one it was released on, and only there.
Dropping above a row and dropping below the row before it are the same move
described twice, so every gap could be aimed at from two sides. The strip
above the first row is the one place a drop under something cannot reach.

A chapter could only be dropped into, never dragged past: taking the whole
row as a place quietly took reordering away. The bottom edge of its header
is the gap now, the rest of the row is still the chapter.

A link showed the sheet of paper whatever it pointed at. The @ menu dropped
the mark on the way into the link, and the refresh that keeps a link current
ran once, while the editor was still empty -- content is poured in afterwards
without an update event, so nothing ever looked again.

The mark in the title bar and the box in a task list were each centred on a
line box rather than on the letters in it, which is not the same as being on
one line. The mark shares the title's baseline; the box is centred on the
capitals and sized in em.

Move to... is divided under headings that are deliberately not shaped like
entries, and each row carries the mark its chapter or notebook wears.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
marcandClaude Opus 5 committed 2026-08-17 11:45:16 +02:00
1 parent 2ffa357dfc
commit a9391cdcf2
15 files changed
+724 -189

No files matched your search

+34 -2
View File
@@ -332,6 +332,14 @@ devices get different starts, because they want different things:
The row under the finger is found with `elementFromPoint`, not with enter/leave
handlers — a finger generates no `pointerover` on anything it did not press.
**A drop lands the row under the one it was released on, and only ever there.**
Dropping above a row and dropping below the row before it are the same move
described twice, so every gap could be aimed at from two sides — which made a
drag hard to aim and harder to read. One direction, one line, drawn under the
row it will land under. The two ends of the list have strips of their own: the
one below the last row was always there, and there is now one above the first,
because that is the single place a drop *under* something cannot reach.
**Rearranging is a mode**, switched on by the handle button beside the sort menu
and off again by itself when the list is left or the order stops being a
hand-made one. Only while it is on does a row wear its grip or move at all. Rows
@@ -348,6 +356,13 @@ hover, there was no way to open it in the first place. It is now placed by
measuring, opens on a tap, unfolds in place on a narrow screen, and flips to the
other side on a wide one when the right would not fit.
*Move to…* holds two different kinds of place, so it **says which is which**:
the notebook itself, then *Chapters here*, then *Other notebooks*. The headings
are deliberately not shaped like entries — small, faint and set apart — because
a heading built like a menu row is a button that does nothing when pressed. Each
row carries the mark its chapter was given or the cover its notebook wears, so a
place is recognised in the menu the same way it is recognised in the list.
### Installing it
The install entry used to appear only when the browser had offered a prompt
@@ -1017,8 +1032,15 @@ took three visits. Its menu therefore holds one *Edit* and one *Remove*.
**A row is put into a chapter by dragging it onto it.** While rearranging is on,
a chapter row takes what is dropped on it and lights up to say so, rather than
growing a drop line above it: a chapter is a place, not a neighbour. Notes and
separators both go in this way.
growing a drop line: a chapter is a place, not a neighbour. Notes and separators
both go in this way.
But it is a neighbour as well, and taking the *whole* row as "into" quietly took
that away — a chapter could no longer be moved among its neighbours, and nothing
could be put in the gap under one. So the **bottom edge of a chapter's header is
the gap** and the rest of it is the chapter. The header, not the row: an open
chapter carries its notes inside that row, and holding over those plainly means
the chapter.
A chapter shows even when the notebook holds nothing else. "Nothing here" is
asked of every row, not of the notes alone — asked of the notes, a notebook whose
@@ -1083,6 +1105,16 @@ still reads newest-first — untouched rows all carry position 0 and fall back t
it — so nothing is lost by starting there, while starting in "last changed" made
both separators and dragging look broken until the sort menu was found.
**A new note is put at the very top, and the list is renumbered to say so.**
Left to the tie-break it landed near the top by age, which is not the same thing:
a separator's position counts the rows above it, so a row appearing without a
renumber left every line one row too high, and the arrangement came apart a
little more with each new note. `placeOnTop` builds the order from the list
*without* the new note — measuring the room after the furniture has moved would
write the misreading back as the truth — and puts the note in front of it. Every
other row keeps its place, and the rows that had never been dragged stop sliding
about, because now they carry a position of their own.
The views are different: "All Notes", "Starred" and the bin are questions asked
of every notebook at once, so there is nothing for an arrangement to belong to
and nowhere to keep it. They start in "last changed" and are not offered the