Conversation
Moving a page was drag & drop only. HTML5 drag & drop has no keyboard path at all, and on a touch screen it does not fire even once — so on a phone moving a page was not awkward, it was impossible. docs/06 carried that as an open point ever since the page's own move picker was dropped. One menu answers both. Its trigger is a real button on every tree row, so it is in the tab order and under a finger; its entries are the four steps every outline editor has — up, down, in under the sibling above, out to behind the parent. Reimplementing the drag on pointer events would have given the touch screen a gesture and the keyboard still nothing. Dragging stays the primary gesture and is untouched: it says where a page lands better than any list can. Where each step lands is `src/domain/move-tree.ts`, away from the menu, because it is a question about the tree and because the order keys are only checkable in isolation. A step that picks a *parent* writes no key and lets the new level sort by title, which is exactly what dropping onto that row already does — the tree must not look different depending on whether a mouse or the keyboard moved the page. A key is written only where a position within a level is genuinely chosen: up, down and out. The trigger follows the "+" on the Pages heading: hidden until the row is hovered or focused, because the tree is read far more often than it is rearranged. A coarse pointer has no hover to reveal it with, so there it is always visible — without that, the touch half of this ticket would have shipped invisible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The four steps reach a neighbour. Filing a page under one at the other end of the wiki is one drag with a mouse and, without one, a dozen repeats of "move down" — so the menu gets a second panel: every page the move may land under plus the top level, in tree order, filterable by name. This is the one thing dragging has no equivalent of, and deliberately so: a drag can only end where the pointer can reach, a list can name a row that is scrolled away or folded shut. Left out are the page itself, its own subtree and the parent it already has — the same three a drop refuses, refused here for the same reason rather than reported as an error after the click. Picking a destination writes no order key, the same as "in" and the same as dropping onto that row. docs/02 said this of the drop; it now says it of choosing a parent, however the parent was chosen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two siblings share an order key whenever their titles normalise identically and neither has been placed by hand. `keyBetween` answers "behind the pair" for equal bounds — right for a drop, wrong for a step, which asks to overtake one row and would pass both. The step back then computed the very same key, so the menu entry looked enabled and did nothing when clicked, because `useMovePage` drops a no-op placement without a word. A tie above or below is now stepped over as a whole run, and any plan that lands the page on the placement it already has is reported as "nowhere to go" — the same answer the first and last row of a level already get, and the menu greys it out before it is tried.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes CON-15.
Moving a page no longer needs a mouse. HTML5 drag & drop has no keyboard path and does not fire on a touch screen at all, so on a phone moving a page was impossible rather than awkward.
What is in it
src/domain/move-tree.ts, away from the menu. A step that picks a parent writes no order key and lets the level sort by title, exactly like dropping onto that row — the tree must not look different depending on what moved the page.keyBetweenanswers "behind the pair" for equal bounds — right for a drop, wrong for a step. A tie is stepped over as a whole run.How to test
Automated: typecheck, lint, tests and build are green.