feat(muya): support same-line display math - #4935

Pushed 7cf518c: the display-math rule is now a linear-time scanner instead of a regex.

A downstream review of this change flagged that inlineDisplayMathRule backtracked quadratically on malformed input — the \. content pairs overlap the (\*) trailing group, so $$ followed by 131,072 backslashes and a stray $ blocked the thread for ~10s (2.5s at 65,536). Since tryChunks runs synchronously during paragraph tokenization, one crafted line could freeze the window on open or paste, so this seemed worth fixing before merge rather than shipping another regexp/no-super-linear-backtracking suppression.

execInlineDisplayMath keeps the exact semantics: content ends at the first unescaped same-line $$; a backslash always escapes the next character (the regex's greedy pair-first behavior, so an escaped closer extends the content); a returned match always has an unescaped closer, so the isLengthEven(to[3]) gate is untouched — the parity group is always empty.

Evidence:

• exhaustive parity sweep of all 349,525 strings of length ≤ 9 over {$, \, a, \n} (prefixed with $$), old regex (through the parity gate) vs scanner: 0 mismatches on both the accepted set and the matched content;
• 131,072 backslashes: 10,045ms → 0ms (65,536: 2,581ms → 0ms);
• 5 new unit tests, including the adversarial input asserted under 500ms and never tokenized as display math.

Re-verified: the touched suites 53/53, tsc --noEmit clean, ESLint 0 errors, CommonMark/GFM conformance unchanged (1344 passed; the same three #4934 round-trip baseline failures as clean develop).

Could we achieve this by modifying the regular expression rather than adding a new rule (inlineDisplayMathRule)?

Thanks @Renakoni, same-line $$ is a feature people have been asking for. I reviewed the PR and pushed maintainer commits to the branch: a merge of the current develop, plus fixes for what the review found. Summary below.

Design: one inline_math regex instead of a scanner

This follows up on my earlier question. $$...$$ is now matched by the existing rule, and execInlineDisplayMath plus the special case in tryChunks are gone:

// `$$...$$` is display math and may contain a lone `$`; `$...$` may not.
inline_math: /^(\$\$(?!\$)|\$)((?:(?!\1)[^\\]|\\.)+)\1(?!\1)/,

• Linear time. The quadratic backtracking you found came from the trailing (\\*) group, not from $$ itself. The single-dollar rule on develop has the same problem: $ plus 131,072 backslashes takes about 6.6s to tokenize. That is now [Bug] A $ followed by a long run of backslashes freezes the editor #5365. The group never changed an accepted match, so dropping it fixes both markers. I checked this over all 1,048,575 strings of up to 11 characters over $, \, a and \n.
• Emphasis priority. Because it is a regular rule, it is also in validateRules. *note $$a*b$$ now keeps the formula, as *note $a*b$ already did. The scanner sat outside the rule tables, so lowerPriority never saw it and the emphasis won.
• Behavior changes compared with the scanner. Over the same input set, every difference between the regex and the scanner (0 unexplained out of 1,048,575) falls into one of two cases:
  • Like $...$, $$...$$ may span a soft line break, so hard-wrapped Energy $$E =\nmc^2$$ renders, as in pandoc.
  • Directly adjacent formulas such as $$a$$$$b$$ need a space between them. The HTML export does not render that form either.

Commits pushed

Not changed here

• Export parity. The marked math extension used by HTML/PDF export and the clipboard still needs whitespace before the opener and whitespace or ?!.,: after the closer, and does not cross newlines. So ($$x$$), 中文$$x$$中文 and a $$ span with a soft break render in the editor but come out raw in export. $...$ has the same gap on develop today, so it belongs in a separate change. The PR description's note that export "already renders $$" holds for whitespace-delimited formulas.
• Caret next to the formula. A caret at either edge of the formula reveals its source, and the paragraph reflows from the centered block to inline source. This is the same reveal-on-caret model as $...$.

Verification

• pnpm -C packages/muya test: 1692 passed. test:spec: 1347 passed. lint, lint:types and check-circular are clean.
• New or updated unit tests fail before each fix and pass after it: the [Bug] A $ followed by a long run of backslashes freezes the editor #5365 timing test, soft break and emphasis in the display-math spec, [Bug] Enter on a paragraph that starts with $$ replaces it with an empty math block #5364 Enter at top level and in a list item, word toggle, and clipboard $$.
• Chrome e2e (same-line-display-math.spec.ts, 7 tests): the new $$ auto-pair, blank-line and nested-overflow tests failed before their fixes and pass now.
• Full local Chromium e2e suite: every failure also fails locally on develop's source (shortcuts, format toolbar, empty-and-tiny, link punctuation). CI is running on 150d66b.

The description still says multiline $$ is left to the block parser and that $$a$$$$b$$ tokenizes as two formulas. This comment supersedes those two points.

Follow-up: $$ now picks display versus inline the way GitHub does. This replaces the "every $$...$$ renders as a centered block" behavior described in my previous comment.

Rule. $$...$$ renders as display math only when it is in a paragraph that holds nothing but $$ formulas (whitespace and line breaks are fine), and that paragraph is not inside a list item. Anywhere else it renders inline, exactly like $...$ (KaTeX displayMode: false). The Markdown source is unchanged.

I checked each case below against GitHub's Markdown API (POST /markdown, which returns js-display-math or js-inline-math):

Tests: 21 editor render cases and 20 export cases. Every inline case failed on 150d66b and passes now. The e2e sentence test now checks that Energy is $$E=mc^2$$ conserved. stays on one line, and the nested-overflow test uses > > > $$...$$, since a list item would render it inline. pnpm -C packages/muya test (1732 passed), test:spec (1347 passed), lint, lint:types and check-circular are clean. Local Chromium e2e failures match those on 150d66b (keyboard-focus specs only).

Follow-up on the $$ display rule: this update drops the list-item exception from my previous comment.

Rule now. $$...$$ renders as display math when its paragraph holds nothing but $$ formulas (whitespace and line breaks are fine). That includes paragraphs inside block quotes and list items. Next to other text in the same paragraph, or in a heading or table cell, it renders inline like $...$.

Why diverge from GitHub in lists. A paragraph content renders when it is created, before it is attached to its list item. Keeping the list exception meant re-rendering $$ contents after attach, and a paragraph moved into or out of a list would stay stale until its next render. Now the decision depends only on the paragraph's own text, so the special re-render hook (Parent.rerenderDisplayMath) is gone and Parent, ListItem and TaskListItem are back to their develop versions.

I also checked how GitHub renders in Chrome. Its inline $$ in text and in list items produces the same MathML as $...$ (27px tall, limits beside ∑), so a CSS-only override that keeps display typesetting would not have matched GitHub either.

Tests: 22 editor render cases and 22 export cases, including nested and task lists and - see $$c$$. pnpm -C packages/muya test (1735 passed), test:spec (1347 passed), lint, lint:types and check-circular are clean. Local Chromium e2e for the math specs is 13/13.