Skip to content

Keep list item open after a removed reference definition - #655

Merged
jgm merged 2 commits into
commonmark:masterfrom
ck0i:fix-item-after-refdef-blank-line
Nov 6, 2026
Merged

jgm merged 2 commits into
commonmark:masterfrom
ck0i:fix-item-after-refdef-blank-line

Conversation

@ck0i

@ck0i ck0i commented Nov 2, 2026

Copy link
Copy Markdown
Contributor

When a list item's only paragraph is a link reference definition, finalize removes the paragraph and the item is left with no children. parse_node_item_prefix reads first_child == NULL as "the item started with a blank line after the marker", so a later blank line with fewer spaces than the item's content indent closes the item. That is why - [r]:x, an empty line, , l renders <li></li> followed by <p>l</p>. The empty-line and two-space variants from the issue keep l in the item, the first only because the LIST_LAST_LINE_BLANK early return in check_open_blocks skips the item check. commonmark.js keeps l in the item in all three cases.

The fix sets a new internal flag, CMARK_NODE__ITEM_HAD_CONTENT, on the parent item when finalize drops a reference-definition paragraph, and parse_node_item_prefix keeps the item open on a blank line when that flag is set. Items that really open with a blank line still end at the next blank line (-, empty line, foo is unchanged). I added the case from the issue to test/regression.txt. It fails before the change and passes after, and the ctest suite passes (api_test 563, spec 652, smart punctuation 16, regression 36) along with the pathological tests.

Fixes #618

When a list item's only paragraph holds nothing but a link reference
definition, the paragraph is removed on finalize and the item is left
without children. parse_node_item_prefix took that to mean the item
started with a blank line, so a later blank line with some spaces, but
fewer than the item's content indent, ended the item. `- [r]:x`, an
empty line, ` `, `  l` put `l` in a paragraph after the list. Mark the
item when such a paragraph is removed and keep it open as cmark does
for an item with children.

Fixes commonmark#618.
@jgm

jgm commented Nov 6, 2026

Copy link
Copy Markdown
Member

Thanks. I tried to edit your regression test on the web interface, just to add "Issue #655" to the description.
Unfortunately, GitHub detected that the file had mixed line endings and normalized the whole thing to Windows line endings, which we don't want. (There is one test with CRs, but the rest of the file should be standard NL endings.)

Can you revert my commit, add Issue #655 to the description (but without changing line endings), and force push?

Revert the web-edit commit that normalized the file to CRLF and re-add
the issue tag with LF endings only.
@ck0i

ck0i commented Nov 6, 2026

Copy link
Copy Markdown
Contributor Author

Got it. Reverted the web edit, added Issue #655 with LF endings only, and force-pushed. Thanks!

@ck0i
ck0i force-pushed the fix-item-after-refdef-blank-line branch from 77f3739 to 9e3b7bd Compare November 6, 2026 18:17
@jgm
jgm merged commit dfd5bdd into commonmark:master Nov 6, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Single-space blank line evicts a list-item continuation

2 participants