Markdown renderer: a stray $ (currency like US$ 500) pairs with the next $ and swallows text as inline math

[seupedro]

Summary

In the web UI, when a rendered message contains a currency dollar sign (e.g. US$ 500) and, later in the same paragraph, a legitimate inline math span ($n$), the renderer pairs the two $ and parses everything between them as one inline KaTeX math token. All whitespace inside collapses (KaTeX math mode) and accented characters get converted to TeX accent commands, producing garbled text like 500pelaresolu\c c\~ao.Taoaclassificou....

This happens whenever a paragraph has two or more $ where the first one isn't intended as math — very common with currency in technical answers.

Minimal reproduction

It cost US$ 50 for each $n$ item.

• Actual: everything from the $ in US$ 50 up to the $ of $n$ is parsed as a single inline-math token (italic glyph soup or a KaTeX error), and $n$ does not render as math.
• Expected: US$ 50 stays literal text; $n$ renders as math.

With accented text (e.g. Portuguese resolução) the swallowed span renders as resolu\c c\~ao, which makes the corruption obvious.

Root cause

dsh-web-frontend bundles micromark-extension-math with the default singleDollarTextMath: true and no edge/flanking rules. In the bundled mathText tokenizer (dist/assets/vendor-*.js, hash varies per build):

1. previous(code) only rejects a $ immediately preceded by another $ — a $ preceded by a letter/digit (as in US$, R$) still opens math.
2. The closing $ run is accepted whenever its length matches the opener — even if the character right before it is a space, or the content starts with whitespace.

So any two stray $ in one paragraph pair up across sentences.

Suggested fix

kramdown/Obsidian-style guards, applied to single-$ math only ($$…$$ flow/display untouched):

1. In previous(code): refuse to open when code is a letter or digit (ASCII 0-9 A-Z a-z, plus non-ASCII letters) → fixes US$ / R$.
2. At the closing attempt: refuse when the character immediately before the closing $ run is a space or line ending; refuse when the content began with whitespace; refuse when the character right after the closing run is a digit (Obsidian rule, avoids closing into $100).

On rejection, call nok so micromark falls back to literal text. That rollback is safe: micromark already supports text constructs that consume and then fail (the extension itself relies on this for unclosed $…), and after the rollback a later $ can still open a legitimate span.

Verified behavior after patching the bundled tokenizer locally:

• US$ 500 … quase todo $n$ → US$ 500 literal, $n$ renders as math ✅
• price $50 and $60 → literal ✅
• $x^2$, $y$, $$E=mc^2$$, multi-line $x\ny$, (see $x$), code spans → unchanged ✅
• space-padded $ x $ → literal (same as kramdown/Pandoc) ✅

Happy to share the patch if useful.

Environment

• @deepseek-ai/dsh / @deepseek-ai/dsh-web-frontend 0.1.1-rc.2, web UI served by dsh --profile web
• Rendering happens client-side (unified/remark pipeline + KaTeX)

[argszero]

Confirmed reproduction in the current source, and one constraint worth flagging before anyone lands a fix: a blanket "remove single-dollar math" would break an intended feature.

Where the bug lives

dsh-web-frontend (here: packages/client/ui-primitives) wires the math grammar in src/markdown/parse.ts:

// parse.ts:39-43  (settled arm)
return fromMarkdown(text, {
  extensions: [gfm(), cjkFriendlyStrong(), mathCompatibility(), math()],
  mdastExtensions: [gfmFromMarkdown(), mathFromMarkdown()],
})

The project does not pass singleDollarTextMath anywhere, so micromark-extension-math's default singleDollarTextMath: true is in effect. That is exactly the config your report describes — the mathText tokenizer opens on any single $ with only a bare previous(code) check (rejects a $ immediately preceded by another $, nothing else), and the closing run is accepted on length match alone, ignoring flanking whitespace.

The constraint: single-dollar math is a tested feature

The existing test suite explicitly asserts single-dollar inline math renders, e.g. tests/markdown.client.spec.tsx:

const source = ['Einstein wrote $E = mc^2$.', '', '$$', '\\frac{\\partial \\mathbf{u}}{\\partial t} ...', '$$', '', '$\\href{javascript:alert(1)}{unsafe}$'].join('\\n')
expect(container.querySelectorAll('.katex')).toHaveLength(3)

$E = mc^2$ is expected to be a single KaTeX element. So the fix cannot be "disable single-dollar math / require \\(...\\)" — that would regress this test and remove a genuinely useful feature.

What that means for the fix shape

Your suggested kramdown/Obsidian-style edge guards are the right direction, applied only to single-$ text math (leave $$…$$ flow and \\(…\\) untouched). Concretely, the guards to add on the mathText opener/closer:

1. previous(code): refuse to open when the char before $ is a letter/digit (0-9 A-Z a-z, non-ASCII letter) → kills US$, R$, 50$.
2. Closing / content: refuse when the content begins or ends with whitespace, or when the char immediately after the closing $ run is a letter/digit → prevents crossing sentence boundaries (the US$ 50 ... $n$ case).

The key subtlety: guard #1 (the opener) and guard #2 (no whitespace/word-tight content) together — a lone $E = mc^2$ must still open (preceded by a space, content non-empty) and close (followed by space/punctuation). That preserves Einstein wrote $E = mc^2$. while keeping US$ 50 literal.

Note: this is a renderer fix in micromark-extension-math's tokenizer behavior, which is a third-party dependency. The project's own mathCompatibility.ts extends the token vocabulary with \\(...\\) and $$ blocks but does not touch the upstream single-dollar mathText construct — so the guard either needs to be added at the math() call options (if micromark-extension-math exposes flanking config), or a thin local wrapper around the upstream mathText tokenizer in mathCompatibility.ts (the project already owns mathText via the backslash construct, so a flank-aware single-dollar variant is consistent with that design).

— argszero

[seupedro]

Thanks for the quick confirmation and for the pointer to parse.ts / mathCompatibility.ts — and good catch on the constraint: agreed, single-dollar math is worth keeping (my own usage depends on it too), so disabling singleDollarTextMath was never on the table. The guards-only shape is the fix.

I already shipped this as a stopgap on my instance by patching the bundled (minified) tokenizer — exactly your two-guard shape, with one difference: I only refused the closing run when the following char is a digit; I'll adopt letter/digit as you suggest (same battery passes). The patched construct, de-minified from the bundle (upstream micromark-extension-math mathText, only the changed parts):

// new state, updated on every consume() in the data/space/line-ending states:
let prevCode      // last consumed char code
let leadingSpace  // latched on the first content char after the opening run: true if space/line ending

// guard 1 — currency-like openers: `US$`, `R$`, `50$`
function previous(code) {
  const isWordChar =
    (code >= 48 && code <= 57) || (code >= 65 && code <= 90) ||
    (code >= 97 && code <= 122) || code > 160 // non-ASCII letters
  if (isWordChar) return false
  return code !== codes.dollarSign ||
    this.events[this.events.length - 1][1].type === 'characterEscape'
}

function sequenceClose(code) {
  // guard 2a — don't close when the char immediately before the run is whitespace
  if (sizeOpen === 1 && (prevCode === codes.space || markdownLineEnding(prevCode))) {
    return nok(code) // micromark rolls the whole construct back to literal text
  }
  if (code === codes.dollarSign) {
    effects.consume(code); prevCode = code; sizeClose++
    return sequenceClose
  }
  if (sizeClose === sizeOpen) {
    // guard 2b — content started with whitespace, or we'd close into a word: `$ x $`, `$n$2`, `$x$y`
    if (sizeOpen === 1 && (leadingSpace || isWordChar(code))) {
      return nok(code)
    }
    effects.exit('mathTextSequence')
    effects.exit('mathText')
    return ok(code)
  }
  token.type = 'mathTextData'
  return data(code)
}

($$…$$ skips all guards via the sizeOpen === 1 checks.)

Two practical notes from validating this against the bundled build (driving the real minified bundle under Node with a DOM shim, 15 behavioral cases):

• The nok-after-consuming rollback is safe and the rest of the paragraph re-parses normally: in price $50 and $60 the construct fails, both dollars stay literal, and a legitimate $x$ later in the same paragraph still renders as math. Opening-edge whitespace has to be latched rather than checked at close time (streaming), and going with a whole-construct nok (instead of the upstream "turn the run into data" fallback) is what prevents the mid-paragraph garbage math when a currency dollar and legit math share a paragraph.
• Multi-line single-$ spans keep working (only edge whitespace is rejected), and $$…$$ flow/display plus code spans are untouched.

Agreed the durable home is a flank-aware single-dollar construct in mathCompatibility.ts — cleaner than patching upstream, since math() exposes no flanking options. The bundle patch above is what I'm running meanwhile; it's been clean in daily use (including the US$ 500 … quase todo $n$ paragraph that motivated the report).