Follow-up from #243 / #247.
Description
In html → markdown, if the text that follows a nested list inside a list item is a literal line of backticks (```), that line becomes a LIST_INDENT-prefixed continuation line. splitOnFences then treats it as a fence opener and pairs it with the next top-level fence. The real code block's body ends up outside the fence and goes through whitespace cleanup. This silently changes code.
This is not a regression from #247. main before #247 also corrupted this input, through its non-greedy list regex. #247's review listed it as a follow-up.
Repro (v2.25.8)
htmlToMarkdown('<ul><li>a<ul><li>b</li></ul>```</li></ul><pre><code> indented\n code here</code></pre>')Actual:
- a
- b
```
```
indented
code here
```
Expected: the <pre> body stays byte-exact ( indented / code here), and the literal ``` stays as text, e.g. escaped as \`\`\`.
Notes
- A top-level
<p>```</p> followed by a code block has the same class of problem.
- A likely fix: escape a leading backtick run in text (non-fence) lines before the cleanup chain runs. That way only fences the converter emitted itself can open a fence. Check storage → markdown for the same issue too.
Follow-up from #243 / #247.
Description
In html → markdown, if the text that follows a nested list inside a list item is a literal line of backticks (
```), that line becomes aLIST_INDENT-prefixed continuation line.splitOnFencesthen treats it as a fence opener and pairs it with the next top-level fence. The real code block's body ends up outside the fence and goes through whitespace cleanup. This silently changes code.This is not a regression from #247. main before #247 also corrupted this input, through its non-greedy list regex. #247's review listed it as a follow-up.
Repro (v2.25.8)
Actual:
Expected: the
<pre>body stays byte-exact (indented/code here), and the literal```stays as text, e.g. escaped as\`\`\`.Notes
<p>```</p>followed by a code block has the same class of problem.