Skip to content

fix: convert a list to the kind a list command asks for - #367

Merged
Azganoth merged 1 commit into
mainfrom
bug/convert-ordered-list-to-bullet-list
Sep 2, 2026
Merged

fix: convert a list to the kind a list command asks for#367
Azganoth merged 1 commit into
mainfrom
bug/convert-ordered-list-to-bullet-list

Conversation

@Azganoth

@Azganoth Azganoth commented Sep 2, 2026

Copy link
Copy Markdown
Owner

Summary

Unordered list reported success on an ordered list, left it ordered, and rewrote the document on the way: the ) the file was written with became ., and the list was forced loose, adding a blank line between every item. The gesture the author asked for did not happen and one they did not ask for did.

toggleListFormat changed the list node's type and nothing else. Each list_item kept the listType: "ordered" and label attributes the preset maintains for rendering, and the preset's own syncListOrderPlugin reads them back on the next transaction: a bullet list whose first item still reads ordered is turned back into an ordered list and rebuilt from { spread: true } alone, which is where the authored marker and the list's tightness went. The bullet-to-ordered direction survived only because the plugin has no mirrored rule for a bullet item inside an ordered list.

The conversion now writes that pair for the list the items end up in, so the plugin reads the document the command meant and leaves it alone. A list that becomes the other kind is a construct that is gone, so it is written in the default form for the one it becomes: a bullet list carries no ordered delimiter and an ordered list no bullet, and the number each item was authored with goes with the ordered list that held it. Each item keeps the padding and the opening line it holds itself, because the items stay the items they were.

Tightness is not a form the conversion replaces, and nothing about it asks for a blank line between items, so the list keeps the spread it had. That reaches the working direction too: Ordered list rebuilt the list from the schema defaults and quietly tightened a loose bullet list.

Related Issue

Closes #364

Verification

markdownCompatibility.test.ts gains ten rows in its List marker form group. Each asserts the node the command left behind beside the saved bytes, because a conversion that never happened writes a file the bytes alone cannot tell from one that did.

Nine cover one conversion each: an ordered list written with ) and one whose items were numbered 3. and 8., both becoming * One and * Two; a bullet list becoming 1. and 2.; a loose list in each direction, which stays loose; four-column marker padding and a task marker carried through; and an item whose content was written on the line after its marker. The tenth converts an ordered list away and back and asserts the default numbering rather than the authored 3. and 8..

Seven of the ten fail on the pre-change source. The three that pass are the tight bullet-to-ordered rows that already worked, which is what makes them the guard rather than the fix. The away-and-back row does not fail an assertion there but crashes inside the preset plugin with RangeError: No node at given position.

The converted document was also compared against the one its saved bytes reopen as, in both directions. They differ only in the number attribute, null on the list the conversion made and read back as positional after reopen, and the resave is byte-identical.

pnpm check:frontend passes, including the corpus round trip. The backend is untouched, so pnpm check:backend was not run.

Not verified: the manual pass over corpus/ in the running application, which covers rendering, interaction, and navigator behavior beyond the automated round trip. The desktop E2E suite was not run locally; its fixtures hold no list conversion.

Notes

An item's label and listType are the preset's bookkeeping for rendering rather than a form the file holds, which is why #364 put them outside its own scope. They are written here because the plugin that reads them back is what reverted the conversion, and the labels the command writes are the ones that plugin would compute, so it stays a no-op instead of correcting the document in a second transaction.

docs/specification.md records the conversion beside the block-command rule #359 settled. docs/decisions.md is unchanged: the rule it already carries under Preserve the form a file was written in covers a block that becomes another construct.

@Azganoth Azganoth added the Bug Something isn't working label Sep 2, 2026
@Azganoth Azganoth self-assigned this Sep 2, 2026
@Azganoth
Azganoth enabled auto-merge (squash) September 2, 2026 16:41
@Azganoth
Azganoth merged commit 72d393e into main Sep 2, 2026
3 checks passed
@Azganoth
Azganoth deleted the bug/convert-ordered-list-to-bullet-list branch September 2, 2026 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unordered list does not convert an ordered list

1 participant