fix: convert a list to the kind a list command asks for - #367
Merged
Conversation
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
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.
Summary
Unordered listreported 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.toggleListFormatchanged the list node's type and nothing else. Eachlist_itemkept thelistType: "ordered"andlabelattributes the preset maintains for rendering, and the preset's ownsyncListOrderPluginreads them back on the next transaction: a bullet list whose first item still readsorderedis 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 listrebuilt the list from the schema defaults and quietly tightened a loose bullet list.Related Issue
Closes #364
Verification
markdownCompatibility.test.tsgains ten rows in itsList marker formgroup. 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 numbered3.and8., both becoming* Oneand* Two; a bullet list becoming1.and2.; 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 authored3.and8..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
numberattribute,nullon the list the conversion made and read back as positional after reopen, and the resave is byte-identical.pnpm check:frontendpasses, including the corpus round trip. The backend is untouched, sopnpm check:backendwas 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
labelandlistTypeare 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.mdrecords the conversion beside the block-command rule #359 settled.docs/decisions.mdis unchanged: the rule it already carries underPreserve the form a file was written incovers a block that becomes another construct.