[haripetrov-stack]

Description

Markdown import decides whether a *, _, ~~ or == run can open or close formatting by looking at the characters on either side of it. The punctuation and whitespace classes listed only ASCII characters, so an en dash, a curly quote, a currency sign or an emoji next to a run counted as a letter. See –**[here](https://example.com)** now. imported as plain text, and its next export escaped the asterisks.

CommonMark 0.31.2 counts every character in the Unicode P and S categories as punctuation, and Zs plus tab, LF, FF and CR as whitespace. Import and the typing shortcuts now use those sets, reading whole code points so astral characters such as 😀 are classified correctly. The backslash, missing from the old ASCII list, now counts as punctuation too.

Export has to follow: Lexical wrote shapes like foo**“bar”**baz, whose markers no longer flank, and 7 of the MarkdownEscaping.test.ts round trips from #9481 failed. The exporter now writes the letter beside such a marker as a numeric character reference (foo**“bar”**baz), which every CommonMark reader decodes to the same text. It writes none inside code or transformer output. A raw backslash right before a marker, or before a character that export escapes with shouldPreserveNewLines, is escaped too. The references are chosen so that micromark, which @lexical/mdast imports with and which reads an emoji as a letter, formats the result the same way (😀**“b”**).

A bare URL, www. host or email that GFM readers would link needs care: a reference inside it changes the link, and GFM readers take markers and code spans after it into the link. When either would happen, export writes the . of www. or the : after the scheme as a reference, so that no reader links it and the text and formatting come through (**www.x.co**a, see https://x.com/a**“x”**). An email that holds a reference has its @ written as @, so that micromark links the whole decoded address.

Import fixes that the new flanking exposed:

• Emphasis that closes before a later code span is applied before that span, so its markers no longer split apart (**a.**x**`c`**).
• A link or other text match no longer takes part of any code span, not only the first (Bug: Equation $ parsing should not bind tighter than code formatting #8687), and the link search stays bounded on lines with many [ or code spans.
• A delimiter run cut by an earlier match reads as it did in the whole text (*)**a*). Text beside a text match that does not cut a run still reads the match's edge as the edge of a line, as on main, so a custom syntax that ends in a letter (user:bob**(admin)**) keeps the formatting after it.
• An escaped backtick before more backticks no longer stops the rest of the run from opening a code span (x\``bb`x), which export writes for a plain backtick before inline code.

Import now finds a line's code spans, emphasis and links, and the matches of other text-match transformers whose patterns do not look behind, once rather than again after each match, and imports the text after each match in a loop, in the same order as before. Long lines import faster than on main, for example 4 s instead of 9 s for 'a **b** [c](d) `e` _f_ ' repeated 1,600 times, and very long paragraphs no longer overflow the stack.

Markdown such as **你好。**世界, which main read as bold, now imports with literal asterisks, as CommonMark, GFM, micromark and markdown-it show it; a CJK-friendly rule for both importers is left for a follow-up.

Known limitations:

• The rule of 3 still allows pairings by remaining run length, as on main (Bug: Markdown export produces invalid markdown for overlapping formats #4895).
• Some overlapping formats around escaped punctuation on both sides of a marker do not round-trip.
• Emphasis can still pair across a link's label, as in x~~[_](u)[~~](u), as on main.
• A literal == in text is not escaped, so it can pair with a highlight marker that both opens and closes. With Unicode punctuation that now includes a highlight next to an emoji or symbol, not only next to ASCII punctuation as on main.
• Escapes and references that export writes inside a bare URL, such as \_, become part of the link in GFM readers, as on main.
• \v beside a marker cannot be written so that both CommonMark and micromark readers agree.

Reported in sveltia/sveltia-cms#1107.

Closes #9407
Closes #9410
Closes #9443

Changeset

.changeset/markdown-unicode-punctuation-flanking.md, a [fix] patch for @lexical/markdown. Its Verify: paragraph covers stored Markdown such as **“bar”**baz and a**\_x**, which now imports with literal asterisks as CommonMark readers show it, and the new character references in export.

Test plan

Command: pnpm exec vitest run --project unit packages/lexical-markdown

Before

With main merged into the original PR head (5debdb3):

     × preserves existing formatted markers after plain text: bold 15ms
     × preserves existing formatted markers after plain text: italic 2ms
     × preserves existing formatted markers after plain text: strikethrough 3ms
     × preserves formatted backslashes next to plain text: bold 4ms
     × preserves formatted backslashes next to plain text: italic 2ms
     × preserves formatted backslashes next to plain text: strikethrough 2ms
     × preserves formatted backslashes next to plain text: bold+italic 2ms
 Test Files  1 failed | 8 passed (9)
      Tests  7 failed | 844 passed (851)

After

 Test Files  9 passed (9)
      Tests  1055 passed (1055)

The new tests cover Unicode and astral punctuation, spec whitespace, character references read back by both @lexical/markdown and @lexical/mdast, formatting beside bare URLs and emails, code-span and link precedence, cut delimiter runs and custom text-match transformers. Import was also compared with markdown-it on random inputs, where it agrees on many more of them than main does, and export round trips were checked through both importers and cmark-gfm on random paragraphs, with none that main got right and this gets wrong.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
lexical	Ready	Preview	Nov 2, 2026 5:27am UTC
lexical-playground	Ready	Preview	Nov 2, 2026 5:27am UTC

[pkg-pr-new]

lexical

npm i https://pkg.pr.new/lexical@9430

@lexical/a11y

npm i https://pkg.pr.new/@lexical/a11y@9430

@lexical/clipboard

npm i https://pkg.pr.new/@lexical/clipboard@9430

@lexical/code

npm i https://pkg.pr.new/@lexical/code@9430

@lexical/code-core

npm i https://pkg.pr.new/@lexical/code-core@9430

@lexical/code-prism

npm i https://pkg.pr.new/@lexical/code-prism@9430

@lexical/code-shiki

npm i https://pkg.pr.new/@lexical/code-shiki@9430

@lexical/compiler

npm i https://pkg.pr.new/@lexical/compiler@9430

@lexical/devtools-core

npm i https://pkg.pr.new/@lexical/devtools-core@9430

@lexical/dragon

npm i https://pkg.pr.new/@lexical/dragon@9430

@lexical/eslint-plugin

npm i https://pkg.pr.new/@lexical/eslint-plugin@9430

@lexical/extension

npm i https://pkg.pr.new/@lexical/extension@9430

@lexical/fast-check

npm i https://pkg.pr.new/@lexical/fast-check@9430

@lexical/file

npm i https://pkg.pr.new/@lexical/file@9430

@lexical/hashtag

npm i https://pkg.pr.new/@lexical/hashtag@9430

@lexical/headless

npm i https://pkg.pr.new/@lexical/headless@9430

@lexical/history

npm i https://pkg.pr.new/@lexical/history@9430

@lexical/html

npm i https://pkg.pr.new/@lexical/html@9430

@lexical/internal

npm i https://pkg.pr.new/@lexical/internal@9430

@lexical/link

npm i https://pkg.pr.new/@lexical/link@9430

@lexical/list

npm i https://pkg.pr.new/@lexical/list@9430

@lexical/mark

npm i https://pkg.pr.new/@lexical/mark@9430

@lexical/markdown

npm i https://pkg.pr.new/@lexical/markdown@9430

@lexical/mdast

npm i https://pkg.pr.new/@lexical/mdast@9430

@lexical/offset

npm i https://pkg.pr.new/@lexical/offset@9430

@lexical/overflow

npm i https://pkg.pr.new/@lexical/overflow@9430

@lexical/plain-text

npm i https://pkg.pr.new/@lexical/plain-text@9430

@lexical/react

npm i https://pkg.pr.new/@lexical/react@9430

@lexical/rich-text

npm i https://pkg.pr.new/@lexical/rich-text@9430

@lexical/selection

npm i https://pkg.pr.new/@lexical/selection@9430

@lexical/table

npm i https://pkg.pr.new/@lexical/table@9430

@lexical/tailwind

npm i https://pkg.pr.new/@lexical/tailwind@9430

@lexical/text

npm i https://pkg.pr.new/@lexical/text@9430

@lexical/utils

npm i https://pkg.pr.new/@lexical/utils@9430

@lexical/y

npm i https://pkg.pr.new/@lexical/y@9430

@lexical/yjs

npm i https://pkg.pr.new/@lexical/yjs@9430

commit: 12f3bb0

[meta-code-review]

Thanks for the thorough work here. The change looks good to me: emphasis flanking in @lexical/markdown now follows CommonMark 0.31.2's Unicode punctuation and whitespace, on import and in the typing shortcuts, and the exporter's character references keep formatting readable for CommonMark readers and for @lexical/mdast. The new tests in LexicalMarkdown.test.ts and MarkdownTransformers.test.ts include 92 cases that fail without the source changes and pass with them. Everything below is optional and non-blocking.

Suggestions (optional)

1. Formatting right after a custom text match that ends in a letter (packages/lexical-markdown/src/importTextTransformers.ts:317). With a mention-style TextMatchTransformer (importRegExp: /@(\w+)/, export writing @bob), mention @bob followed by bold (admin) exports as @bob**(admin)**, as before, but now re-imports as literal **(admin)**, and the next export escapes the asterisks. The same happens with italic “a” and bold "x". On main the text after a match was read as the start of a line, so this round-tripped. The text after a match now takes the match's last character as its neighbour, and the exporter can't put a reference inside transformer output, so there is no way to write this shape that the importer accepts. The PR and changeset describe only delimiter runs that a match cuts (*)**a*). AGENTS.md (Backwards Compatibility) asks to keep existing behaviour that callers may depend on, so consider giving the text after (and before) a text match a punctuation or line-edge neighbour when the match doesn't cut a delimiter run, and adding a round-trip test with a mention-style transformer. The built-in and playground transformers aren't affected, since their syntax ends in ), $ or :.
2. A referenced U+2028, U+2029, U+FEFF or U+000B after a bare URL (packages/lexical-markdown/src/MarkdownExport.ts:737, used at :958). findSpoiledLinks ends a URL at any JavaScript whitespace, but these four characters are letters for CommonMark, so they get written as references (
), and GFM readers keep those in the link. Plain see , bold http://x.co/, then U+2028 and x exports as see **http://x.co/**
x, which @lexical/mdast reads as one link with the bold lost. Counting referenced positions as URL characters in that scan (isLinkCharacter(text[end]) || isReference[end]) would close it.
3. Changeset (.changeset/markdown-unicode-punctuation-flanking.md). CONTRIBUTING.md (Changesets) asks a fix that changes observable behaviour to say what to verify. If item 1 stays as it is, the Verify: paragraph could name it. Splitting the long summary paragraph into its import and export changes would also make the release note easier to scan.

Question for maintainers: Markdown stored by earlier versions with a marker between a letter and Unicode punctuation, such as **“bar”**baz and especially CJK labels like **注意：**请先登录, used to import as bold. It now imports with literal asterisks, which are escaped on the next save. CommonMark requires this, and the changeset's Verify: paragraph documents it, with a CJK-friendly rule left for a follow-up. Is shipping strict flanking for stored documents in a patch release the intended direction?

The CI workflows haven't run on this head yet because they're awaiting approval, so a maintainer still needs to run them before merge.

[meta-code-review]

Optional: here the text after a match takes the match's last character as its neighbour, and the reused line scan reads it the same way. With a mention-style transformer whose output ends in a letter, @bob**(admin)** (Lexical's own export of mention @bob then bold (admin)) now re-imports as literal **(admin)**, where main read the rest as the start of a line. The exporter can't put a reference inside transformer output, so this shape can't be written in a form the importer accepts. Consider a punctuation or line-edge neighbour when the match doesn't cut a delimiter run, plus a round-trip test with such a transformer.

[meta-code-review]

Nit: U+2028, U+2029, U+FEFF and U+000B match \s/\p{Cc} here, so the scan at line 958 ends a URL at them. CommonMark reads them as letters, though, so beside a marker they go out as references (
), and GFM readers keep those in the link: plain see , bold http://x.co/, then U+2028 and x exports as see **http://x.co/**
x, which @lexical/mdast reads as one link with the bold lost. Treating a referenced position as a URL character in that scan (isLinkCharacter(text[end]) || isReference[end]) would fix it.

[meta-code-review]

Thanks for the thorough work here. The change looks good to me: emphasis flanking in @lexical/markdown now follows CommonMark 0.31.2's Unicode punctuation and whitespace, on import and in the typing shortcuts, and the exporter's character references keep formatting readable for CommonMark readers and for @lexical/mdast. Everything below is optional and non-blocking.

Suggestion (optional)

1. A delimiter run right after a text match reads two ways (packages/lexical-markdown/src/importTextTransformers.ts:51-62, used at :358-371). After a link or other text match, the rest of the line reuses the whole line's emphasis scan, unless opensOnlyBesideEdge finds that the leading run opens only beside the line edge. That check compares canOpen alone. But the match's last character also decides whether the run can close, and CommonMark's rule of 3 depends on that: "If one of the delimiters can both open and close emphasis, then the sum of the lengths of the delimiter runs containing the opening and closing delimiters must not be a multiple of 3 unless both lengths are multiples of 3." Text that ends before a later match is scanned fresh with the edge as its neighbour. So the same run reads differently depending on what follows it on the line:

   Markdown	This PR	main	CommonMark
   [a](u)**#*	literal **#*	* + italic #	literal **#*
   [a](u)**#* [b](v)	* + italic #	* + italic #	literal **#*
   [a](u)**(*s**	**( + italic s + *	* + italic (s	* + italic (s

   The description says text beside a text match still reads the match's edge as the edge of a line, as on main. Comparing canClose as well, and sending either difference to findPairAtEdge, would make the two paths agree. A test that [a](u)**#* reads the same with and without a trailing [b](v) would pin this down. So would one line with more than 64 characters after a match, where findPairAtEdge starts trying prefixes, since no current test reaches the reuse path there. Lexical's own exports don't appear to produce these shapes, so only hand-written Markdown is affected.

Question for maintainers: Markdown stored by earlier versions with a marker between a letter and Unicode punctuation used to import as bold. Examples are **“bar”**baz and, more commonly, CJK labels such as **注意：**请先登录, which earlier versions of the exporter wrote themselves. These now import with literal asterisks, which the next save escapes. CommonMark requires this, the changeset's Verify: paragraph documents it, and a CJK-friendly rule is left for a follow-up. AGENTS.md (Backwards Compatibility) says "when in doubt, assume external code depends on the current behavior". Is shipping strict flanking for stored documents in a patch release the intended direction?

[meta-code-review]

Optional: this compares only canOpen. Beside the match's last character the run may also be able to close, and CommonMark's rule of 3 depends on that. So [a](u)**#* keeps literal **#* while [a](u)**#* [b](v) (deferred and scanned fresh at the edge) italicizes #, and main italicizes both. Comparing canClose too, and sending either difference to findPairAtEdge, would make the two paths agree.

[meta-code-review]

Thanks, this looks good to me. Flanking now follows CommonMark 0.31.2's Unicode punctuation and whitespace definitions. The exporter's references keep formatting readable for CommonMark readers and @lexical/mdast. The import loop is faster and no longer recursive. Everything below is optional and non-blocking.

A behavior decision for maintainers. With ：, 。 and 「 counted as punctuation (packages/lexical-markdown/src/utils.ts:66), CJK Markdown such as **注意：**请先登录, **你好。**世界 and 世界**「你好」** now imports with literal asterisks; main imported all three as bold. Export writes the same nodes as **注意：**请先登录. That is what CommonMark and GFM readers show, and the PR description and changeset say so. Still, it is a visible change for Chinese and Japanese content, where full-width punctuation sits directly beside text. Is the team happy to ship the strict behavior now and add the CJK-friendly rule in the follow-up, or should that rule land in the same release?

Optional nits

• [a](u)*`c`)** now imports italic code c and an italic ). The link is applied before the code span (packages/lexical-markdown/src/importTextTransformers.ts:279-288), and the run after it reads the link's end as a line edge (:110). CommonMark reads that * as both-flanking, so the rule of 3 keeps it literal, as main did.
• **)*(.`*b!****_ loses both italics. The bold's content is re-read with the closing run as context (importTextTransformers.ts:406-415). That makes the leftover ** both-flanking, and the rule of 3 then counts its length as 2 instead of 4. main keeps the italics. Both inputs are contrived and close to the rule-of-3 limitation the PR already lists (#4895).
• AGENTS.md ("Commits and Pull Requests") asks the Test plan's ### Before to show the failing output before the change. The current Before shows main's escaping tests failing against an earlier head of this PR. A run of the new tests against main would show what they catch.

[meta-code-review]

Optional, for maintainers: counting full-width CJK punctuation (：, 。, 「) as punctuation makes **注意：**请先登录 and **你好。**世界 import with literal asterisks, where main imported them as bold. That matches CommonMark 0.31.2, but it is a visible change for Chinese and Japanese content. Is shipping the strict rule now, with the CJK-friendly rule as a follow-up, the intended order?

[meta-code-review]

Optional nit: applying a link that ends before a code span first means the run after it reads the link's end as a line edge, so [a](u)*`c`)** now imports italic code and an italic ). CommonMark (and main) keep it literal, because that * is both-flanking and the rule of 3 stops it from pairing with **. It is rare, so feel free to leave it for the rule-of-3 follow-up (#4895).

[meta-code-review]

Thanks for this. The change looks good to me: classifying punctuation and whitespace with the Unicode sets follows CommonMark 0.31.2, the new tests fail on main and pass here, and the exported references read back through both @lexical/markdown and @lexical/mdast. A few suggestions, all optional and non-blocking:

1. Stored CJK Markdown (a call for maintainers). Markdown that main exported and read back as bold, such as **注意：**请先登录, now imports with literal asterisks, and saving it again writes \*\*注意：\*\*请先登录. That is what CommonMark specifies, and the changeset's Verify: already says so. Bold labels that end in full-width punctuation right before CJK text are common in Chinese and Japanese writing, so it may be worth shipping the CJK-friendly follow-up in the same release. CONTRIBUTING.md files a behaviour-changing fix as [fix] with Verify:, as you did. AGENTS.md (Backwards Compatibility) describes [breaking] with Migration:/Detect: for changes callers depend on, if maintainers prefer that category here.
2. Edge case right after a link (packages/lexical-markdown/src/importTextFormatTransformer.ts, findPairAtEdge, lines 161–195). [x](u)**:*a.** imports on main as x, *, italic :a., reading the run after the link beside the edge of a line as the description intends, but here as x, **:, italic a., *. The search for the pair that the run after the link opens stops before the scan's next emphasis (end), but that pair can contain it. Returning false (so the rest is scanned on its own) when end comes from the next emphasis or code span would keep the edge reading. It is a narrow shape.
3. Export cost (packages/lexical-markdown/src/MarkdownExport.ts, findSpoiledLinks, line 897). Any paragraph whose text contains www., :// or @ builds a masked copy and three typed arrays, even when no reference or marker touches a link. For a 300-paragraph document with a bare URL in each paragraph, $convertToMarkdownString takes about 30 ms against about 7.5 ms on main (12.6 ms without the URLs). An early exit when no link run sits next to a marker or reference would help apps that export on every change.
4. Test plan. The ### Before block shows the original head failing the MarkdownEscaping.test.ts round trips. AGENTS.md (Commits and Pull Requests) asks for the real failing output before the change, so pasting main's run of the new tests would show what they catch.

[meta-code-review]

Optional: when no pair is found in prefixes that end before end, this keeps the whole-line scan, but the pair the edge run opens can contain the next emphasis. [x](u)**:*a.** imports on main as x, *, italic :a. (the run after the link read beside the edge of a line, as the description intends) and here as x, **:, italic a., *. Returning false when end came from the next emphasis or code span, so the rest is scanned on its own, would keep the edge reading.

[meta-code-review]

Optional: any text piece with www., :// or @ sends the whole paragraph through the masked copy and typed arrays below, even when no reference or marker touches a link. A 300-paragraph document with one bare URL per paragraph exports in about 30 ms against about 7.5 ms on main. An early exit when no link run is next to a marker or reference would recover most of that.

[meta-code-review]

Thanks for this! The change looks good to me: classifying punctuation and whitespace with the Unicode sets follows CommonMark 0.31.2, the new tests fail on main and pass here, and the exported references read back through both @lexical/markdown and @lexical/mdast. A few suggestions, all optional and non-blocking:

1. Quadratic escape with shouldPreserveNewLines (packages/lexical-markdown/src/MarkdownExport.ts, line 566). /\\+(?=[*_`~])|[*_`~]/g retries \\+ from every backslash of a run that no marker follows, so exporting a text node of 16,000 backslashes takes about 570 ms, against 0.1 ms on main. Matching the whole run and checking the character after it gives the same output in linear time:

   output = output.replace(
     /\\+|[*_`~]/g,
     (escaped, offset: number, text: string) =>
       escaped[0] !== '\\'
         ? `\\${escaped}`
         : /[*_`~]/.test(text[offset + escaped.length] ?? '')
           ? escaped + escaped
           : escaped,
   );

2. Stored CJK Markdown (a call for maintainers). Markdown that main exported and read back as bold, such as **注意：**请先登录, now imports with literal asterisks, and saving it again writes \*\*注意：\*\*请先登录. That is what CommonMark specifies, and the changeset's Verify: says so. Bold labels that end in full-width punctuation right before CJK text are common in Chinese and Japanese writing, so it may be worth shipping the CJK-friendly follow-up in the same release.

3. Export cost beside bare URLs (MarkdownExport.ts, spoilLinks, line 872). Any paragraph whose text contains www., :// or @ builds the masked copy and the prefix sums even when no reference or marker touches a link; 300 such paragraphs export in about 11 ms against about 2 ms on main. An early exit for that case would help apps that export on every change.

4. A run right after a link (packages/lexical-markdown/src/importTextFormatTransformer.ts, findPairAtEdge, lines 153–197). [x](u)**:*a.** imports on main as x, *, italic :a., reading the run after the link beside the edge of a line as the description says, but here as x, **:, italic a., *. Returning false when end comes from the next emphasis or code span, so that the rest is scanned on its own, would keep the edge reading. It is a narrow shape.

5. Test plan. The ### Before block shows the original head merged with main failing the MarkdownEscaping.test.ts round trips. AGENTS.md (Commits and Pull Requests) asks for the real failing output of the command before the change, so pasting main's run of the new tests would show what they catch.

[meta-code-review]

Optional: \\+(?=[*_~])is retried from every backslash of a run that no marker follows and backtracks through the rest of it each time, so this is quadratic in the run (16,000 backslashes: about 570 ms, against 0.1 ms onmain`). Matching the whole run and checking the next character gives the same output in linear time:

Suggested change

	output = output.replace(/\\+(?=[*_`~])|[*_`~]/g, escaped =>
	escaped[0] === '\\' ? escaped + escaped : `\\${escaped}`,
	);
	output = output.replace(
	/\\+|[*_`~]/g,
	(escaped, offset: number, text: string) =>
	escaped[0] !== '\\'
	? `\\${escaped}`
	: /[*_`~]/.test(text[offset + escaped.length] ?? '')
	? escaped + escaped
	: escaped,
	);

[meta-code-review]

Nit: when no pair is found before end and end comes from the next emphasis or code span, this keeps the whole-line scan, which read the edge run beside the text match. So [x](u)**:*a.** imports as x, **:, italic a., * instead of main's x, *, italic :a.. Returning false here in that case (so the rest is scanned on its own) would keep the edge reading the description promises.

[meta-code-review]

Thanks for this! The change looks good to me: classifying punctuation and whitespace with CommonMark 0.31.2's Unicode sets is what the spec asks for, the new tests fail on main and pass here, and the exported references read back through both @lexical/markdown and @lexical/mdast. A few suggestions, all optional and non-blocking:

1. Quadratic escape with shouldPreserveNewLines (packages/lexical-markdown/src/MarkdownExport.ts, line 566). /\\+(?=[*_`~])|[*_`~]/g retries \\+ from every backslash of a run that no marker follows, so exporting a text node of 16,000 backslashes takes about half a second, against well under a millisecond on main. Matching the whole run and checking the character after it gives the same output in linear time:

   output = output.replace(
     /\\+|[*_`~]/g,
     (escaped, offset: number, text: string) =>
       escaped[0] !== '\\'
         ? `\\${escaped}`
         : /[*_`~]/.test(text[offset + escaped.length] ?? '')
           ? escaped + escaped
           : escaped,
   );

2. Stored CJK Markdown (a call for maintainers). Markdown that main exported and read back as bold, such as **注意：**请先登录, now imports with literal asterisks, and saving it again writes \*\*注意：\*\*请先登录. That is what CommonMark specifies and how @lexical/mdast already reads it, and the changeset's Verify: paragraph says so. Bold labels that end in full-width punctuation right before CJK text are common in Chinese and Japanese writing, so it may be worth shipping the CJK-friendly follow-up in the same release.

3. Test plan. The ### Before block shows the original head merged with main failing the MarkdownEscaping.test.ts round trips. AGENTS.md (Commits and Pull Requests) asks for the real failing output of the command before the change, so pasting main's run of the new tests would show what they catch.

The CI workflows have not run on this head yet; they are waiting for a maintainer to approve them for the fork.

[meta-code-review]

Optional, non-blocking: \\+(?=[*_~])is retried from every backslash of a run that no marker follows, so this is quadratic in the run (16,000 backslashes take about half a second to export, against well under a millisecond onmain`). Matching the whole run and checking the character after it gives the same output in linear time:

output = output.replace(
  /\\+|[*_`~]/g,
  (escaped, offset: number, text: string) =>
    escaped[0] !== '\\'
      ? `\\${escaped}`
      : /[*_`~]/.test(text[offset + escaped.length] ?? '')
        ? escaped + escaped
        : escaped,
);