Conversation
Co-authored-by: jlongster <[email protected]>
Co-authored-by: Brendonovich <[email protected]>
…co#50428) Co-authored-by: Shoubhit Dash <[email protected]>
Co-authored-by: jayair <[email protected]>
Co-authored-by: simonklee <[email protected]>
Co-authored-by: jlongster <[email protected]>
Co-authored-by: rekram1-node <[email protected]>
Co-authored-by: rekram1-node <[email protected]>
…51977) Co-authored-by: rekram1-node <[email protected]>
Contributor
|
The following comment was made by an LLM, it may be inaccurate: |
3 of 6 tasks
…malyco#51981) Co-authored-by: rekram1-node <[email protected]>
The katex extension only recognized \(...\) inline math and block math
requiring newlines right after the opening $$ and before the closing $$.
Most LLM chat output uses $..$ for inline math and single-line $$..$$
for display math, so those formulas currently render as raw source.
Extend the existing extension rather than adding a new one:
- inline: try $..$ after \(...\) fails, with display mode for $$..$$
- block: accept single-line and same-line $$..$$ alongside the existing
newline-delimited form
- start hints: report the earliest $ for inline math and \n$$ for block
math so marked can split paragraphs around glued display math
Currency guards keep money amounts as plain text: the opening $ must
not be followed by whitespace, the closing $ must not be preceded by
whitespace nor followed by a digit, and the content cannot contain $
or newlines ("costs $5 and $10", "$1,000 to $2,000" stay literal).
Unclosed delimiters are left as text; invalid latex renders as an
inline error via the existing throwOnError:false path.
Co-Authored-By: Claude Code <[email protected]>
wulart
force-pushed
the
feat/markdown-dollar-math
branch
from
September 29, 2026 12:51
bcd31a7 to
ad24d62
Compare
Author
|
Retargeting to the v2 line where merges are landing — superseded by #52087. The gap exists identically on v2 (its katex extension also only matches (...)). |
1 task done
3 tasks done
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
20 participants
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.
Issue for this PR
Closes #51725 (same gap reported in #39170, #38030, #34407, #49486)
Type of change
What does this PR do?
#34850 dropped
$...$inline math in favor of\(...\), fixing the currency false positives of the old unguarded matcher — but chat output overwhelmingly uses$...$for inline and single-line$$...$$for display math, which now renders as raw source (#51725 et al).This reopens the delimiter question with the piece that was missing when #34850 was decided: guards on the dollar matcher. The old matcher (
(?<!\$)\$(?!\$)...) had none, socosts $5 and $10matched as math. This one requires:$not followed by whitespace$not preceded by whitespace$not followed by a digit$or newline inside the contentso
costs $5 and $10,from $1,000 to $2,000, and an unclosed$(mid-stream output) all stay plain text.Implementation stays inside the existing katex extension (
marked-parser.tsx, +32/−8): the inline tokenizer falls back to$...$when\(...\)doesn't match ($$...$$inside a paragraph renders in display mode); the block regex accepts single-line and same-line$$...$$alongside the existing newline-delimited form;starthints now report the earliest$(inline) and\n$$(block) so marked can split paragraphs around display math glued to preceding text.\(...\)and$$\n...\n$$handling is untouched; no new dependencies.#48329 covers this ground plus
\[...\]with a larger rewrite — this is deliberately the minimal version scoped to the reported issues. Happy to extend the guard set if reviewers see cases it misses.How did you verify your code works?
11 new cases in
packages/ui/src/context/marked-parser.test.ts: single-dollar inline, symbol-heavy inline, CJK in\text{}, single-line block, block glued to text, in-paragraph$$, money amounts, unclosed delimiters, invalid latex, dollars literal inside code, plain markdown unaffected. All recognition cases fail on unmodifieddevfirst; the money/unclosed/code-literal cases pass there since they assert non-rendering.bun testinpackages/ui— 38 pass (incl.marked-regression.test.ts)bun testinpackages/session-ui— 83 pass (the parser's consumer)tsgo --noEmitcleanScreenshots / recordings
Rendering fix — the new tests show the before/after directly (
<p>$x^2$</p>becomes<span class="katex">…); happy to attach a rendered screenshot on request.Checklist