Front matter strips everything if no ending delimiter detected

[digitalmoksha]

It seems like if the start of front matter is detected, and if there is no ending delimiter, it strips off everything. As opposed to not treating it as front matter.

So

---
frontmatter
--

text

generates no HTML. Do you think this is a bug, or working as designed?

Currently in GitLab we abort front matter processing if we don't detect the ending delimiter.

[gjtorikian]

IMHO this should be reported and treated as an error: Frontmatter not closed, no matching delimiter found, something like that.

It's more likely that someone would want --- to be treated as frontmatter, than to expect the rest of the document to parse with mismatched -.

[digitalmoksha]

I know what you're saying, but we don't generate errors with anything else that isn't formatted correctly. It just renders as if that syntax is not supported. So it seems like it would be a little out of character.

[gjtorikian]

True, but this feels more like document metadata, and therefore more significant than in-line text formatting.

I could see it being necessary for a larger build pipeline process. Like: "convert this markdown document, and if the frontmatter has type: posts, put it in directory, or if it's type: pages, put it in another." That feels significantly different than malformed or unexpected HTML within the content itself.

[digitalmoksha]

What the would the error look like, just a paragraph prefixed to the markdown above the supposed front matter?

[kivikakk]

IMHO this should be reported and treated as an error: Frontmatter not closed, no matching delimiter found, something like that.

It's more likely that someone would want --- to be treated as frontmatter, than to expect the rest of the document to parse with mismatched -.

I think that's pretty reasonable, but I'm kind of inclined to think that should be a separate interface that can actually report errors in the document. So far there's just no way to report that, and I don't think putting error information into the output (it'd have to go in the AST; where else could it go?) is ever really a good idea.

[kivikakk]

It seems like if the start of front matter is detected, and if there is no ending delimiter, it strips off everything. As opposed to not treating it as front matter.

This is a regression, I'm assuming an unintentional side-effect of #508. We'll look into it!

[digitalmoksha]

If an error doesn't go into the rendered document, then I think the rendering should be as if the front matter option is not turned on, rather than showing nothing.

[kivikakk]

So

---
frontmatter
--

text

generates no HTML.

@digitalmoksha Can you give me a solid reproduction? I'm struggling to write a test case that exhibits this; there might be a particular set of options needed.

$ printf '---\nfrontmatter\n--\n\ntext\n'
---
frontmatter
--

text
$ printf '---\nfrontmatter\n--\n\ntext\n' | ./comrak-0.32.0-aarch64-apple-darwin --front-matter-delimiter ---
<hr />
<h2>frontmatter</h2>
<p>text</p>
$

[digitalmoksha]

Wow, you know what it is? If you go to https://gitlab-org.gitlab.io/ruby/gems/gitlab-glfm-markdown/, you can see it happen - remove the ending front matter ---, and you can see it happen.

But in narrowing it down, I realized there is a ---, a markdown <hr>, at the end above the footnotes. So it ends up recognizing that as the end, and just removes everything. Since there are then no footnotes, they don't display either.

[kivikakk]

Hah! I guess this is part and parcel of the perils of using software (Comrak) to process something (YAML frontmatter) it doesn't actually understand. I confirm this behaviour is unchanged since (random example: whatever version of Comrak is in Nixpkgs 24.11) 0.23.0.

[digitalmoksha]

GitLab has the same problem, except they don't remove the front matter, it's wrapped in a code block. So it's kind of easier to diagnose. 🤦

[digitalmoksha]

Sorry for the noise

[kivikakk]

No worries! 🤍

[gjtorikian]

Consider it a fun holiday chat. 😆