A formatting command drops the authored form of the block it changes

[Azganoth]

Summary

Leafdown records the form a block was authored in and writes it back, but the formatting commands have no rule for that form. Two commands that make the same change to a heading disagree about whether it survives: Increase heading level carries the node's attributes through and keeps the form, while Heading 1 through Heading 6 rebuild the block from the level alone and drop it.

The file then gains the unrequested rewrite the preservation program exists to prevent, arriving one gesture later than a save would have delivered it. Neither behavior is a decision about form; the difference is which ProseMirror helper each command reached for.

Steps to reproduce

1. Open a document containing Setext one on one line and === on the next.
2. Run Heading 2.
3. Save the document and read the file.

Expected behavior

Setext one over ---. That is the form the heading was authored in, at the level the command asked for, and it is what Increase heading level already writes for the same change.

Whatever rule is chosen, the two paths to one level change agree.

Actual behavior

## Setext one. The authored form is gone.

Measured by driving the editor mount on main at 71897f80, the merge of #358, which is where a heading first carries a form:

Document	Command	Saved
Setext one / ===	Increase heading level	Setext one / ---
Setext one / ===	Heading 2	## Setext one
# Closed atx #	Heading 3	### Closed atx

adjustSelectedHeadingLevels dispatches setNodeMarkup(pos, undefined, { ...node.attrs, level }, node.marks), which carries every attribute the node holds. toggleHeading reaches setSelectionTextBlockType(view, "heading", { level }), which builds the block from the named attributes alone and leaves every other attribute at its schema default.

Related context

• Related issues or pull requests: A heading's authored form is rewritten on save #316 and fix: keep the form a heading was authored with #358 introduce the heading form this is measured against. A table's omitted outer pipes are added on save #349 and fix: keep the marker and numbers a list was authored with #355 add the table and list forms the same question applies to. Preserve the authored form of a Markdown file on save #251 is the serialization program; its Scope puts editing-surface behavior outside it, which is why this is a standalone issue rather than a sub-issue.
• Documentation, decisions, or prior investigation: Preserve the form a file was written in in docs/decisions.md, which ranks content, closure, and form but says nothing about what an editing command does to a recorded form.

Done when

• A stated rule for what a formatting command does with the authored form of the block it changes: preserve it, reset it, or recompute it.
• Heading 1 through Heading 6 agree with Increase heading level and Decrease heading level on a heading's form.
• The commands that rebuild a block from named attributes are audited, and the ones that drop a preserved form are named here whether or not each is changed under this issue.
• Regression coverage asserts the rule in both directions, so preserving a form through one command cannot silently reset it through another.
• The specification records what a formatting command does to an authored form.

Notes, logs, screenshots

The list commands were probed alongside the headings and the result was inconclusive: the caret landed inside the existing list and toggled it off rather than acting on the trailing paragraph. Whether format.unorderedList and format.orderedList drop a list's recorded marker is unmeasured and part of the audit above.

Typora was measured on the same question for comparison. It preserves a construct's authored form through an edit to that construct, including a level-three heading closed by a single hash and a setext heading whose underline is far shorter than its text. Its three markdown preferences do not reformat an existing construct.

Implementation direction

setNodeMarkup with the node's own attributes spread is already the preserving form, so the smaller half of the work is making the toggle path match it. The rule is the larger half, because a level change and a paragraph-to-heading conversion are not obviously the same question: the first has a form to keep and the second has none.

Out of scope

• What form a construct with no authored form takes, which is its own issue.
• Undo and redo, which restore the attributes the history holds.
• Whether a formatting preference should exist at all.

[Azganoth]

Command audit

Every formatting command that rebuilds a block from named attributes, measured by driving the editor mount on main at df4329a8 and reading the saved bytes, with the document's node type read alongside them where the bytes alone could not tell a failed change from a successful one.

Command	Mechanism	Result
Heading 1 through Heading 6	setBlockType	Drops separator, closingSequence, and underline. Fixed under this issue.
Increase/Decrease heading level	setNodeMarkup, attributes spread	Preserving. The reference behavior.
Paragraph, Clear block formatting	setBlockType	Construct change to a paragraph, which holds no form. # Closed atx # writes Closed atx.
Code block	setBlockType, names language: ""	Deletes a fence's info string. Content rather than form, and a named attribute, so the rule this issue settles does not reach it. Filed as #365.
Ordered list, bullet to ordered	setNodeMarkup(pos, type), no attributes	Marker resets, correctly: a - is no ordered delimiter. Item padding survives, - Padded writing 1. Padded.
Unordered list, ordered to bullet	same	Does not convert at all, and loosens the list on the way. Filed as #364.
Task list, Toggle task checked	setNodeMarkup, attributes spread	Preserving. - Padded writes - [ ] Padded, and 1) One writes 1) [ ] One.
Blockquote, Increase/Decrease list indent	wrapIn, lift, sinkListItem, liftListItem	No rebuild. # Closed atx # writes > # Closed atx #.
Table commands	table, row, and cell attributes carried	Preserving. outerPipes: "none" survives Add row below on the node, and the pipes that row writes are the documented blank-cell fallback, since Add column after on the same table still writes none.

Two entries drop something and are not changed here, because neither is a dropped form.

Unordered list is the row the Notes section left unmeasured, and the answer is not the one the question expected. The command does not convert an ordered list at all: it sets the list node's type, each list_item keeps the listType: "ordered" attribute the preset maintains for rendering, and the preset's own syncListOrderPlugin reverts the type on the next transaction, rebuilding the node from { spread: true } alone. 1) One / 1) Two comes back as 1. One, a blank line, 1. Two — still ordered, the delimiter gone and the list forced loose. The marker loss is what this issue's rule allows anyway, since ordered to bullet is a construct change; the failed conversion and the tightness change are neither, which is why they are #364.

Code block names { language: "" }, and those attributes decide both what a new block gets and what an existing one is recognized by. A block with an info string fails the second test, so it is rebuilt rather than removed, and the language goes. An info string is content, and no code block records a fence form today, so nothing here turns on form. That is #365.

The bullet-to-ordered direction, the task commands, the wrapping commands, and the table commands were checked against the same question and none of them drop a recorded form.