Background
Originally proposed in #150 (now closed).
When the user hovers between an open folder row and its first child row, today the only valid drop is "first child of the folder." There is no way to drop the dragged node as a sibling of the folder (i.e., into the folder's parent at the next index).
This is asymmetric with how items and closed folders behave: dragging between an item and the next row, the user can slide horizontally to drop at any ancestor level. Open folders with visible children lose that affordance because the cursor between the folder and its first child is locked to one level.
Expected behavior
When hovering in the gap between an open folder `F` and its first child `C`:
- Sliding the cursor right (deeper) → drop as first child of `F` (today's behavior).
- Sliding the cursor left (shallower) → drop as next sibling of `F` (or grandsibling, etc., bounded by `F`'s ancestor chain).
Why #150 didn't deliver this
PR #150 refactored `computeDrop` from 4 branches to 2 and introduced a `getDropLevel` helper that supports a slidable level for the "open folder" case. However, when `above` is an open folder with children, `below` is always its first child at `above.level + 1`, so the bounding logic computes `min = max = above.level + 1` and the level is forced. The horizontal slide never engages. The refactor compiles and passes the (single) existing test, but does not deliver the user-visible behavior its title claims.
Likely shape of the fix
The constraint comes from `getNodesAroundCursor` — when hovering at the bottom half of an open folder, it returns `[folder, firstChild]`, which forces `below.level = folder.level + 1` and pins the slide range. Two possible directions:
- Loosen the lower bound for this specific case. When `above` is an open folder and `below` is its first child, treat `below` as if it were the folder's next sibling (or null) for the purpose of computing `min`. This widens the slide range to the folder's ancestor levels.
- Detect the gap explicitly. When hovering in the small band right at the boundary between the folder row and its first child row, compute the drop level from `hoverLevel` against the folder's ancestor chain rather than against `below`.
Either approach should preserve today's default (drop as first child) when the cursor isn't pulled left.
Prerequisites
`compute-drop.ts` has no unit tests today (it's called out in the source as "the most complex, tricky function in the whole repo"). Any change here should land alongside a test suite covering the existing branches at minimum, so future refactors don't silently regress.
Related
Background
Originally proposed in #150 (now closed).
When the user hovers between an open folder row and its first child row, today the only valid drop is "first child of the folder." There is no way to drop the dragged node as a sibling of the folder (i.e., into the folder's parent at the next index).
This is asymmetric with how items and closed folders behave: dragging between an item and the next row, the user can slide horizontally to drop at any ancestor level. Open folders with visible children lose that affordance because the cursor between the folder and its first child is locked to one level.
Expected behavior
When hovering in the gap between an open folder `F` and its first child `C`:
Why #150 didn't deliver this
PR #150 refactored `computeDrop` from 4 branches to 2 and introduced a `getDropLevel` helper that supports a slidable level for the "open folder" case. However, when `above` is an open folder with children, `below` is always its first child at `above.level + 1`, so the bounding logic computes `min = max = above.level + 1` and the level is forced. The horizontal slide never engages. The refactor compiles and passes the (single) existing test, but does not deliver the user-visible behavior its title claims.
Likely shape of the fix
The constraint comes from `getNodesAroundCursor` — when hovering at the bottom half of an open folder, it returns `[folder, firstChild]`, which forces `below.level = folder.level + 1` and pins the slide range. Two possible directions:
Either approach should preserve today's default (drop as first child) when the cursor isn't pulled left.
Prerequisites
`compute-drop.ts` has no unit tests today (it's called out in the source as "the most complex, tricky function in the whole repo"). Any change here should land alongside a test suite covering the existing branches at minimum, so future refactors don't silently regress.
Related