Skip to content

fix: remove up to the fence indentation from each content line - #4074

Open
Kjubikstronk wants to merge 1 commit into
markedjs:masterfrom
Kjubikstronk:fix-fence-indent-stripping
Open

fix: remove up to the fence indentation from each content line#4074
Kjubikstronk wants to merge 1 commit into
markedjs:masterfrom
Kjubikstronk:fix-fence-indent-stripping

Conversation

@Kjubikstronk

Copy link
Copy Markdown

Marked version: 18.0.11 (53cb13f)

Markdown flavor: CommonMark

Description

CommonMark removes up to N spaces from each line of a fenced code block when the opening fence is indented by N. indentCodeCompensation only strips a line that is indented at least N:

if (indentInNode.length >= indentToCode.length) {
  return node.slice(indentToCode.length);
}

return node;

So a line indented less than the fence keeps all of its indentation instead of losing what it has.

Expectation

For example 133, a fence indented by three spaces:

aaa
aaa
aaa

gives aaa\n aaa\naaa\n. The four space line keeps one, the two space line keeps none.

Result

aaa\n aaa\n aaa\n. The four space line is handled correctly, the two space line keeps both of its spaces.

What was attempted

node.slice(Math.min(indentInNode.length, indentToCode.length)) covers both directions, so the branch goes away rather than gaining a case.

I diffed the exact-match failure set across the whole spec before and after: 133 moves to passing and nothing else changes, in both the CommonMark and GFM runs.

This is the same blind spot as #4073. htmlIsEqual builds @markedjs/html-differ with only ignoreSelfClosingSlash and ignoreComments, so ignoreWhitespaces stays at its default of true. Whitespace inside pre/code is significant, so 133 was already reported as passing and carries no shouldFail flag. The spec suite therefore cannot protect this fix either, which is why the tests below assert exact output.

A correction to something I wrote in #4073 and in #4050, since it is wrong and has been repeated since: I described example 318 as a lexer bug. It is not. Code token text has no single convention, '```\nb\n```' gives "b" while ' b\n' gives "b\n", and Renderer.code's strip-then-append exists to reconcile that. The token is correct under marked's own convention and the renderer is where the trailing blank lines are lost. I tried the obvious fix, moving the newline inside the fences capture group and reducing the renderer to const code = text. It fixes 126, 130, 144, 237 and 318, and breaks 117, 128, 211, 236, 253 and 272, because indented code and fenced code inside a blockquote genuinely have no trailing newline in the token and rely on the renderer supplying it. Fixing 318 properly means agreeing one convention across every code token path, which changes token.text for fenced code and is a decision for the team rather than a drive-by PR.

Contributor

  • Test(s) exist to ensure functionality and minimize regression (if no tests added, list tests covering this PR); or,
  • no tests required for this PR.
  • If submitting new feature, it has been documented in the appropriate places.

Two tests in test/unit/marked.test.js under fenced code block indentation. The first fails without the change; the second, a line indented more than the fence, passes either way as a control. Full spec suite (1789) and unit suite (193) pass.

Committer

In most cases, this should be a different person than the contributor.

CommonMark removes up to N spaces from each line of a fenced code block when
the opening fence is indented by N. indentCodeCompensation only stripped lines
indented at least N, so a line indented less kept all of its indentation.

Fixes CommonMark example 133. The spec suite did not catch it because
htmlIsEqual leaves html-differ's ignoreWhitespaces at its default of true.
@vercel

vercel Bot commented Aug 30, 2026

Copy link
Copy Markdown

@Kjubikstronk is attempting to deploy a commit to the MarkedJS Team on Vercel.

A member of the Team first needs to authorize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant