Problem
context
For a document where a same-line-closed math block is followed by trailing text on that same line, e.g.:
1. $$a$$
1. $$b$$ trailing
3) $$c$$
expectation
I expected $$b$$ trailing to close on its own line, same as $$b$$ alone would, with trailing parsed as ordinary paragraph text and the following list item left untouched
bug
Instead, math_block_dollar's same-line-close check only recognizes a close when the closing $$ is the last thing on the line, or when it's followed by a label suffix ($$...$$ (label)). Any other trailing content fails both branches, so haveEndMarker stays False and the rule falls through to the multi-line scan, which greedily consumes every line until it finds the next $$ anywhere later in the document, including the following list item's marker and content, as literal math text
There's no error or exception, the parser just silently produces the wrong tree:
$ python3 -c "
from markdown_it import MarkdownIt
from mdit_py_plugins.dollarmath import dollarmath_plugin
md = MarkdownIt().use(dollarmath_plugin)
print(md.render('1. \$\$a\$\$\n1. \$\$b\$\$ trailing\n 3) \$\$c\$\$\n'))
"
# 'trailing', the second list item marker, and 'c' all get absorbed into the first math token's contentI found this bug while working on idempotency/canary testing of mdformat-obsidian's against a real-world Obsidian vault. Re-formatting the corrupted output isn't idempotent either, list structure differs again on the second pass
problem
This is a problem for anyone using dollarmath_plugin on documents that mix ordered/lettered lists with inline-closed math blocks (common in Obsidian vaults, MkDocs docs, and similar authoring tools), because the parser silently swallows unrelated following content into the math token instead of failing to match or erroring. It's a silent correctness bug in the parse tree, not just a downstream formatting quirk
Related issues checked before filing
- #125 ("Dollarmath math blocks inside blockquotes retains
> in the equation") is in the same rule family but a different defect: blockquote-marker leakage into token.content, not this same-line-close ambiguity
- #60 ("converted formula lost its delimiters") is unrelated: a renderer/HTML-output configuration issue with
markdown_it core, not a parsing bug.
Problem
context
For a document where a same-line-closed math block is followed by trailing text on that same line, e.g.:
expectation
I expected
$$b$$ trailingto close on its own line, same as$$b$$alone would, withtrailingparsed as ordinary paragraph text and the following list item left untouchedbug
Instead,
math_block_dollar's same-line-close check only recognizes a close when the closing$$is the last thing on the line, or when it's followed by a label suffix ($$...$$ (label)). Any other trailing content fails both branches, sohaveEndMarkerstaysFalseand the rule falls through to the multi-line scan, which greedily consumes every line until it finds the next$$anywhere later in the document, including the following list item's marker and content, as literal math textThere's no error or exception, the parser just silently produces the wrong tree:
I found this bug while working on idempotency/canary testing of
mdformat-obsidian's against a real-world Obsidian vault. Re-formatting the corrupted output isn't idempotent either, list structure differs again on the second passproblem
This is a problem for anyone using
dollarmath_pluginon documents that mix ordered/lettered lists with inline-closed math blocks (common in Obsidian vaults, MkDocs docs, and similar authoring tools), because the parser silently swallows unrelated following content into the math token instead of failing to match or erroring. It's a silent correctness bug in the parse tree, not just a downstream formatting quirkRelated issues checked before filing
>in the equation") is in the same rule family but a different defect: blockquote-marker leakage intotoken.content, not this same-line-close ambiguitymarkdown_itcore, not a parsing bug.