What's wrong
YAML (and Pandoc's metadata blocks) allow a YAML block opened by --- to be closed by the end-of-document marker .... IsDelimiterLine (Frontmatter/Frontmatter.cs, ~line 436) only accepts ---, and the closing scan in TrySplitFrontmatterBlocks (~line 375) uses it. So a block closed with ... is not closed; the scan keeps going until the next --- anywhere in the document, typically a markdown horizontal rule.
Repro
string doc = "---\ntitle: A\n...\n# Heading\n\nImportant paragraph.\n\n---\n\nMore text\n";
Frontmatter.RemoveFrontmatter(doc);
// "More text\n" <- "# Heading" and "Important paragraph." are gone
Frontmatter.ReplaceFrontmatter(doc, new() { { "title", "B" } });
// "---\ntitle: B\n---\nMore text\n" <- same body loss
Frontmatter.ExtractBody(doc); // "More text"
Frontmatter.ExtractFrontmatter(doc); // null, although "title: A" is valid frontmatterWith no later --- the document is treated as having no frontmatter at all, e.g. AddFrontmatter returns the input unchanged rather than recognising the existing title: A block.
Why it matters
Documents authored for Pandoc commonly use ... as the closing marker. Running Remove/Replace/ExtractBody on them silently deletes body content up to the first horizontal rule. This is data loss on write, not just a missed read.
This differs from #140 (a --- rule on the first body line) and #139 (Combine deleting an unparseable block): here the block boundary itself is wrong.
Suggested fix
Accept a line whose TrimEnd() is ... as a closing delimiter only (never as an opener) in the close loop of TrySplitFrontmatterBlocks. Keep the original closer when rewriting, or normalise to ---; either is fine as long as it is documented.
Acceptance criteria
ExtractFrontmatter on the document above returns { title: A }.RemoveFrontmatter/ExtractBody return a body that starts with # Heading.- A lone
... line at the top of a document is still not treated as an opener.
What's wrong
YAML (and Pandoc's metadata blocks) allow a YAML block opened by
---to be closed by the end-of-document marker....IsDelimiterLine(Frontmatter/Frontmatter.cs, ~line 436) only accepts---, and the closing scan inTrySplitFrontmatterBlocks(~line 375) uses it. So a block closed with...is not closed; the scan keeps going until the next---anywhere in the document, typically a markdown horizontal rule.Repro
With no later
---the document is treated as having no frontmatter at all, e.g.AddFrontmatterreturns the input unchanged rather than recognising the existingtitle: Ablock.Why it matters
Documents authored for Pandoc commonly use
...as the closing marker. Running Remove/Replace/ExtractBody on them silently deletes body content up to the first horizontal rule. This is data loss on write, not just a missed read.This differs from #140 (a
---rule on the first body line) and #139 (Combine deleting an unparseable block): here the block boundary itself is wrong.Suggested fix
Accept a line whose
TrimEnd()is...as a closing delimiter only (never as an opener) in the close loop ofTrySplitFrontmatterBlocks. Keep the original closer when rewriting, or normalise to---; either is fine as long as it is documented.Acceptance criteria
ExtractFrontmatteron the document above returns{ title: A }.RemoveFrontmatter/ExtractBodyreturn a body that starts with# Heading....line at the top of a document is still not treated as an opener.