Display math inside a blockquote has its `> ` prefix doubled on round trip

[rundel]

A $$ ... $$ display-math block placed inside a blockquote parses with the blockquote > prefix retained inside the math content string (e.g. "\n> p = q\n> "). The qmd writer then re-prefixes every line with > when emitting the blockquote, producing > > p = q and > > $$. Each pass through the round trip adds another > level.

$ printf '> Before\n> $$\n> p = q\n> $$\n> After\n'
> Before
> $$
> p = q
> $$
> After

$ printf '> Before\n> $$\n> p = q\n> $$\n> After\n' | cargo run --bin pampa --
[ BlockQuote [Para [Str "Before", SoftBreak, Math DisplayMath "\n> p = q\n> ", SoftBreak, Str "After"]] ]

$ printf '> Before\n> $$\n> p = q\n> $$\n> After\n' | cargo run --bin pampa -- -t qmd
> Before
> $$
> > p = q
> > $$
> After

$ printf '> Before\n> $$\n> p = q\n> $$\n> After\n' | cargo run --bin pampa -- -t qmd | cargo run --bin pampa --
[ BlockQuote [Para [Str "Before", SoftBreak, Math DisplayMath "\n> > p = q\n> > ", SoftBreak, Str "After"]] ]

This seems like a parser bug (math content retains the blockquote prefix bytes) rather than a writer bug.

From quarto-web:

• https://github.com/quarto-dev/quarto-web/blob/8b1be24df1c9301f2700c77e41e7a9f789535717/docs/manuscripts/authoring/_equations.qmd#L17

[cscheid]

This is a pretty bad one - thanks for spotting it! The fix isn't tiny but it seems doable. PR incoming in a few.

[cscheid]

The robot got scared of the same changes I was scared of:

⏺ The grammar approach causes too much friction with the existing parser flow. Let me revert and try a more targeted AST-extraction fix.

but it has more intestinal fortitude, and so it found the next best fix, a hack-ish AST post-processing fix. We take those.

[rundel]

It looks like there may be a couple of edge cases remaining:

Labeled display math inside a blockquote retains > in math text on round-trip

Labeled display math inside a blockquote round-trips with a literal > left in the math content. The reader correctly strips the blockquote continuation on the first pass (Math text starts with \n), but the writer emits the math as > [$$...$$]{attr} — the [ shifts the $$ column from 2 to 3, and the column-strip then refuses to consume the > on > p(x) because column 2 is p, which is not in {>, space, tab}. The result is Math.text starting with \n> p(x)\n.

$ printf -- '> Let x.\n> $$\n> p(x)\n> $$ {#eq-p}\n> Done.\n'
> Let x.
> $$
> p(x)
> $$ {#eq-p}
> Done.

$ printf -- '> Let x.\n> $$\n> p(x)\n> $$ {#eq-p}\n> Done.\n' | cargo run --quiet --bin pampa --

[ BlockQuote [Para [Str "Let", Space, Str "x.", SoftBreak, Span ( "eq-p" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\np(x)\n"], SoftBreak, Str "Done."]] ]

$ printf -- '> Let x.\n> $$\n> p(x)\n> $$ {#eq-p}\n> Done.\n' | cargo run --quiet --bin pampa -- -t qmd

> Let x.
> [$$
> p(x)
> $$]{#eq-p .quarto-math-with-attribute}
> Done.

$ printf -- '> Let x.\n> $$\n> p(x)\n> $$ {#eq-p}\n> Done.\n' | cargo run --quiet --bin pampa -- -t qmd | cargo run --quiet --bin pampa --

[ BlockQuote [Para [Str "Let", Space, Str "x.", SoftBreak, Span ( "eq-p" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\n> p(x)\n"], SoftBreak, Str "Done."]] ]

In the wild (paths in quarto-dev/quarto-web):

• https://github.com/quarto-dev/quarto-web/blob/baeab38627fcc3f3a9ea3ca3ea689ece413df65d/docs/manuscripts/authoring/_equations.qmd#L17-L19 — Poisson p(x) equation rendered inside a > blockquote example.

Labeled display math drops a column of interior whitespace on round-trip

After the #181 column-strip fix, the reader strips one column from interior lines of a labeled display math block ($$ ... $$ {#label}) even at top level (no blockquote, no list). The writer emits the math wrapped as [$$...$$]{attr}, which puts $$ at column 1 (after [); the reader's C becomes 1 and any leading space on interior lines is silently consumed.

$ printf -- '$$\na\n  b\n$$ {#eq-x}\n'
$$
a
  b
$$ {#eq-x}

$ printf -- '$$\na\n  b\n$$ {#eq-x}\n' | cargo run --quiet --bin pampa --

[ Para [Span ( "eq-x" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\na\n  b\n"]] ]

$ printf -- '$$\na\n  b\n$$ {#eq-x}\n' | cargo run --quiet --bin pampa -- -t qmd

[$$
a
  b
$$]{#eq-x .quarto-math-with-attribute}

$ printf -- '$$\na\n  b\n$$ {#eq-x}\n' | cargo run --quiet --bin pampa -- -t qmd | cargo run --quiet --bin pampa --

[ Para [Span ( "eq-x" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\na\n b\n"]] ]

In the wild (paths in quarto-dev/quarto-web):

• https://github.com/quarto-dev/quarto-web/blob/baeab38627fcc3f3a9ea3ca3ea689ece413df65d/docs/authoring/cross-references.qmd#L378-L383 — Black-Scholes equation has lines + \mathrm r ... and \mathrm r \mathrm C that lose one space on every round trip.

[cscheid]

Colin I've other things to do :lolsob: (no, I'm joking, keep these coming, they're great!)

[cscheid]

Yikes, this is extremely cursed. @rundel since you're deep into investigating the problem: the fundamental issue here is that $$...$$ really wants to be a block node and not an inline node, because of the way it allows linebreaks. But it is an inline node, and so it doesn't have any notion of handling block continuation markers (which is how code blocks handle the internal > > >... from block quotes).

I unfortunately don't see a clean way out of this. Many many documents have displaymath nodes inside paragraphs, and it's just a coincidence that the vast majority of these don't have displaymath inside blockquotes. I'm investigating locally but this seems super nasty :/

[rundel]

My "investigations" amount to scaffolding that runs round trip testing on quarto-web qmd documents and then asking claude to categorize the failures and generate issues for each class.

[rundel]

I very very much do not have my head wrapped around the bigger issue here but I had Claude take a stab at fixing both follow-ups on a local feature branch. Sharing here in case it's useful, seemed to resolve issues above and did not obviously break anything else based on the existing tests. May be undesirable given that it treats the math span differently from other spans.

Claude's thoughts:

Diagnosis

Both follow-up bugs trace back to the writer, not the reader. Thepost-process at crates/pampa/src/pandoc/treesitter_utils/postprocess.rsfolds Math + (Space?) + Attr into Span(("id", ["quarto-math-with-attribute", ...userClasses], userKv), [Math]) on the read side, and the qmd writer's generic write_span then
re-emits that Span with the same [...]{attrs} bracket-wrapper it uses for every other Span. For a multi-line block-shaped inline (display math), that wrapper:

• Shifts the opening $$ column by 1 (top level) or by 1+N (nested), which is what then trips strip_continuation_prefix. For Bug A the 3-byte test [> p] fails the {>, space, tab} check and the > leak survives; for Bug B the 1-byte test [ ] passes and chews one column of real interior whitespace per round trip.

• Is also semantically off — Pandoc inline spans aren't meant to wrap block-shaped content with line breaks. Every labeled equation in quarto-web is written in the $$\n...\n$$ {#id} shape, not [$$...$$]{#id}, so the writer is producing a form no human ever authors.

The reader's column-strip helper is doing the structurally correct thing given the input it sees. The asymmetry is on the emit side.

Fix

One branch added to write_span in crates/pampa/src/writers/qmd.rs, between the existing editorial-markers branch and the generic [ ... ]{attrs} fallback. Detects the marker class injected by the post-process, drops it on emit, and writes the math directly:

if classes.first().is_some_and(|c| c == "quarto-math-with-attribute")
    && let [crate::pandoc::Inline::Math(math)] = span.content.as_slice()
{
    write_math(math, buf, ctx)?;
    let clean_classes: Vec<String> = classes.iter().skip(1).cloned().collect();
    let clean_attr = (id.clone(), clean_classes, keyvals.clone());
    if !is_empty_attr(&clean_attr) {
        write!(buf, " ")?;
        write_attr(&clean_attr, buf, ctx)?;
    }
    return Ok(());
}

No grammar change. No reader change. The existing strip_continuation_prefix becomes correct again for free once the writer stops shifting the column.

A nice side effect: the same branch fixes the cosmetic ugliness for inline labeled math too — $x$ {#fl} instead of [$x$]{#fl .quarto-math-with-attribute}. Inline math wasn't losing content (no line breaks → no column strip), but the bracket-wrapper output was equally not-what-anyone-writes.

Verification (pampa input ≡ pampa input | pampa -t qmd | pampa)

Bug A — labeled display math in blockquote

$ printf -- '> Let x.\n> $$\n> p(x)\n> $$ {#eq-p}\n> Done.\n' | cargo run --quiet --bin pampa --
[ BlockQuote [Para [Str "Let", Space, Str "x.", SoftBreak,
  Span ( "eq-p" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\np(x)\n"],
  SoftBreak, Str "Done."]] ]

$ printf -- '> Let x.\n> $$\n> p(x)\n> $$ {#eq-p}\n> Done.\n' | cargo run --quiet --bin pampa -- -t qmd
> Let x.
> $$
> p(x)
> $$ {#eq-p}
> Done.

$ printf -- '> Let x.\n> $$\n> p(x)\n> $$ {#eq-p}\n> Done.\n' | cargo run --quiet --bin pampa -- -t qmd | cargo run --quiet --bin pampa --
[ BlockQuote [Para [Str "Let", Space, Str "x.", SoftBreak,
  Span ( "eq-p" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\np(x)\n"],
  SoftBreak, Str "Done."]] ]

Math DisplayMath "\np(x)\n" — no > leak, identical AST on the
second pass.

Bug B — top-level labeled display math with interior whitespace

$ printf -- '$$\na\n  b\n$$ {#eq-x}\n' | cargo run --quiet --bin pampa --
[ Para [Span ( "eq-x" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\na\n  b\n"]] ]

$ printf -- '$$\na\n  b\n$$ {#eq-x}\n' | cargo run --quiet --bin pampa -- -t qmd
$$
a
  b
$$ {#eq-x}

$ printf -- '$$\na\n  b\n$$ {#eq-x}\n' | cargo run --quiet --bin pampa -- -t qmd | cargo run --quiet --bin pampa --
[ Para [Span ( "eq-x" , ["quarto-math-with-attribute"] , [] ) [Math DisplayMath "\na\n  b\n"]] ]

The two spaces before b survive the round trip.

Wild examples from quarto-web

• docs/manuscripts/authoring/_equations.qmd (Poisson p(x) callout)

• docs/authoring/cross-references.qmd (Black-Scholes equation, the one with + \mathrm r ... and \mathrm r \mathrm C lines)

Both round-trip byte-for-byte identical at the AST level and produce clean qmd on the writer side — interior whitespace preserved, no > leakage, no quarto-math-with-attribute marker leaking into the emitted attribute set.

Scope

This is the smallest fix that removes the two regressions. It doesn't touch the broader "should display math be a block node?" tension — that one's still lurking but doesn't need to be unblocked just to make these two cases correct.

A nearby edge case I did not try to address: user-authored [$$...$$]{.foo} spans (without the marker class) still go through the generic bracket-wrap path on emit and the column-strip helper on read. That's pre-existing behaviour, and the only way to author it is by hand-writing the bracket form anyway. Happy to file a follow-up if this turns out to bite anyone in practice.

[rundel]

The above assumes "quarto-math-with-attribute" will only ever be at index 0 which may not hold in the real world but not sure about the likelihood/relevance of that edge case.