Inline parser: apostrophe after a code span trips Q-2-7 (Unclosed Single Quote)

[gordonwoodhull]

Claude kept hitting Q-2-7 when writing items in the hub-client changelog. Apostrophe seems to be a special case that works in Pandoc.

Summary

The inline grammar's smart-quote rule treats ' immediately after a closing backtick (code-span boundary) as an opening single quote, even when followed by letters as in a possessive. Pandoc treats the same construct as a possessive and emits no error. As a result, common technical-writing patterns like `setAst`'s callback trip Q-2-7 (Unclosed Single Quote).

Reproducer

printf "x \`code\`'s gate\n" | cargo run --bin pampa -- -t json -i -

Output:

Error: [Q-2-7] Unclosed Single Quote
 1 │ x `code`'s gate
   │         ┬
   │         ╰── This is the opening quote. If you need an apostrophe, escape it with a backslash.

Pandoc reads the same input as a possessive without complaint.

Scope

Pattern	Result	Why
`code`'s gate	FAIL	post-codespan ' promoted to opening
`code`'foo bar	FAIL	same
`code` 's gate	FAIL	whitespace between doesn't help
`code`\'s gate	PASS	escaped apostrophe
word's gate	PASS	letter-letter → possessive
`code`'s and `other`'s pair	PASS	two opens form a balanced pair
`code`'s and word's pair	FAIL	only one promoted-to-opening

The angle brackets in patterns like `<AssetManifestContext>`'s are a red herring — backticks alone are the trigger.

Real-world incidents

This has tripped the hub-client changelog at least twice:

• 0c78b1a4 (2026-05-08) — diagnosis blamed <Tag> HTML-like content; the angle brackets were coincidental.
• d7d7e063 (2026-05-10) — same pattern in plan changelog entries; rewritten in plain prose to clear the parse.

Proposed fix

In tree-sitter-markdown-inline's grammar, extend the rule for opening single quote so a ' immediately after a closing backtick — more generally, after any inline-end token — is treated as a possessive when the next character is a letter. This is the same heuristic that already handles word's. Pandoc's smart-quote algorithm is "an apostrophe between letters, or after a markup boundary that resolves to letters, is a possessive."

After regenerate + build, add a test case to the inline grammar's corpus and a passing case to resources/error-corpus showing that `code`'s no longer fires Q-2-7.

Workarounds available today

1. Pair them deliberately in the same block (two close-backtick apostrophes form a smart-quote pair).
2. Backslash-escape: `code`\'s.
3. Rephrase so the apostrophe is inside a word (e.g. "the setAst callback's behavior").

Related

• Internal: bd-1qk5 (this issue's origin), bd-kk0a (writer-side escape for unbalanced apostrophes — a parser fix here would obviate part of bd-kk0a's scope).
• crates/pampa/snapshots/error-corpus/text/006.snap, 009.snap — current Q-2-7 examples.
• resources/error-corpus/_autogen-table.json:18686 — parser-state mapping table.

[gordonwoodhull]

Pandoc-comparison findings (verified against jgm/pandoc HEAD)

Looked at how Pandoc handles the same construct. Source paths below refer to jgm/pandoc.

The actual rule, from source

src/Text/Pandoc/Parsing/Smart.hs:

singleQuoted inlineParser = do
  singleQuoteStart
  (B.singleQuoted . mconcat <$>
    try (withQuoteContext InSingleQuote (many1Till inlineParser singleQuoteEnd)))
   <|> pure "\8217"

singleQuoteStart = do
  failIfInQuoteContext InSingleQuote
  guard =<< notAfterString          -- opening `'` rejected if previous token is a Str
  try $ do
    char '\''
    void $ lookAhead (satisfy (not . isSpaceChar))

singleQuoteEnd = try $ do
  char '\''
  notFollowedBy alphaNum            -- closing `'` rejected if next char is alphanum

The rule is symmetric: open-' may not follow a Str token; close-' may not precede an alphanumeric character. singleQuoted speculatively consumes a balanced span via many1Till, and falls back to a lone \8217 via try/<|> when no valid close is found.

Pandoc's actual behavior, empirically

Ran three variants through pandoc -f markdown+smart -t native:

Input	Pandoc AST	Verdict
`foo`'s gate.	two Strs, the first \8217s	Correct — no close exists, backtracks to apostrophe
`foo`'s and `bar`'s pair.	two apostrophes	Correct — candidate close in `bar`'s is followed by s (alphanum), so singleQuoteEnd rejects
`foo`'s and the systems' condition.	Quoted SingleQuote [...]	Misparse — ' in systems' is followed by space, so singleQuoteEnd succeeds, and the span balances

The third row is load-bearing: Pandoc has the same fundamental ambiguity. It just doesn't surface it as an error — it silently produces a wrong AST. Q-2-7 in our parser is exposing the same misclassification.

Implications for this issue

1. The original proposed fix in the bead ("letter after ' after closing backtick ⇒ possessive") is a local heuristic that handles common cases but doesn't generalize.
2. "Match Pandoc behavior" is not a clean fix on its own. It would convert Q-2-7 errors into silent AST mis-quoting in cases like row 3. But it does at least clear the most common pain (rows 1 and 2).
3. A defensible target is be at least as good as Pandoc: adopt the symmetric notAfterString / notBeforeAlphanum predicates and the speculative-balance + fallback structure. That eliminates the bead's failing cases Fix yaml-tags non-deterministic write #1, Cmd + S should do nothing #2, Pasting a URL adds $0 #3, Extract DoubleBufferedIframe and Preview from Editor #7 from the scope table and matches Pandoc on cases that are inherently ambiguous.
4. There's a separate, harder question (out of scope here): can we do better than Pandoc by biasing the speculative balance toward apostrophe interpretation when the opening ' follows an inline-end token? That would catch row 3 too, but needs design work.