Successive Footnotes fail parsing #31

New Issue

claunia · 2026-01-29T14:21:47Z

claunia commented

2026-01-29 14:21:47 +00:00

Originally created by @Jither on GitHub (Jun 23, 2016).

Well, "fail" is relative here - since footnote syntax doesn't have any exact specification.

However, I'd expect this test to succeed:

[Test]
public void TestSuccessiveFootnotes()
{
    var md = @"Here is a footnote[^1]. And another one[^2]. And a third one[^3]. And a fourth[^4].

[^1]: Footnote 1 text

[^2]: Footnote 2 text

[^3]: Footnote 3 text

[^4]: Footnote 4 text
";
    var document = Markdown.Parse(md, new MarkdownPipelineBuilder().UseFootnotes().Build());

    var group = document.OfType<FootnoteGroup>().Single();
    Assert.AreEqual(4, group.Count); // Fails - group.Count is 2.
}

To be more specific, when using ToHtml(), Footnote 1 and 3 are rendered as footnotes, while 2 and 4 are rendered as paragraphs.

The reason seems to be that when entering FootnoteParser.TryOpen on the second footnote, this will cause a return:

if (processor.IsCodeIndent || processor.CurrentContainer.GetType() != typeof(MarkdownDocument) )
{
    return BlockState.None;
}

... due to CurrentContainer still being the previous footnote. I'm not confident enough with the parser to see where the correct place would be for popping back out to the document container.

From some other parsers, it seems it's even feasible to break out without an empty line (according to babelmark: php-markdown-extra, pandoc, multimarkdown, kramdown, minima, maruku; and in Javascript e.g. remarkable/markdown-it). I.e. this would render the same:

Here is a footnote[^1]. And another one[^2]. And a third one[^3]. And a fourth[^4].

[^1]: Footnote 1 text
[^2]: Footnote 2 text
[^3]: Footnote 3 text
[^4]: Footnote 4 text

... and that always seemed ideal to me for most uses of footnotes - but it's always rather complex to tell in Markdown syntax, what conflicts this might cause with other parsers.

Originally created by @Jither on GitHub (Jun 23, 2016). Well, "fail" is relative here - since footnote syntax doesn't have any exact specification. However, I'd expect this test to succeed: ``` csharp [Test] public void TestSuccessiveFootnotes() { var md = @"Here is a footnote[^1]. And another one[^2]. And a third one[^3]. And a fourth[^4]. [^1]: Footnote 1 text [^2]: Footnote 2 text [^3]: Footnote 3 text [^4]: Footnote 4 text "; var document = Markdown.Parse(md, new MarkdownPipelineBuilder().UseFootnotes().Build()); var group = document.OfType<FootnoteGroup>().Single(); Assert.AreEqual(4, group.Count); // Fails - group.Count is 2. } ``` To be more specific, when using `ToHtml()`, Footnote 1 and 3 are rendered as footnotes, while 2 and 4 are rendered as paragraphs. The reason seems to be that when entering `FootnoteParser.TryOpen` on the second footnote, this will cause a return: ``` csharp if (processor.IsCodeIndent || processor.CurrentContainer.GetType() != typeof(MarkdownDocument) ) { return BlockState.None; } ``` ... due to `CurrentContainer` still being the previous footnote. I'm not confident enough with the parser to see where the correct place would be for popping back out to the document container. From some other parsers, it seems it's even feasible to break out without an empty line (according to babelmark: php-markdown-extra, pandoc, multimarkdown, kramdown, minima, maruku; and in Javascript e.g. remarkable/markdown-it). I.e. this would render the same: ``` markdown Here is a footnote[^1]. And another one[^2]. And a third one[^3]. And a fourth[^4]. [^1]: Footnote 1 text [^2]: Footnote 2 text [^3]: Footnote 3 text [^4]: Footnote 4 text ``` ... and that always seemed ideal to me for most uses of footnotes - but it's always rather complex to tell in Markdown syntax, what conflicts this might cause with other parsers.

claunia added the bug label 2026-01-29 14:21:47 +00:00

claunia closed this issue

2026-01-29 14:21:47 +00:00

claunia commented

2026-01-29 14:21:49 +00:00

@xoofx commented on GitHub (Jun 23, 2016):

Thanks for the report! Indeed, I will have to put a little bit more tests for footnotes...

This is fixed by commit c8a28a1

@xoofx commented on GitHub (Jun 23, 2016): Thanks for the report! Indeed, I will have to put a little bit more tests for footnotes... This is fixed by commit c8a28a1

claunia commented

2026-01-29 14:21:52 +00:00

@xoofx commented on GitHub (Jun 23, 2016):

Woops, I completely forgot the last case. Sorry, this is not fixed completely 😅

@xoofx commented on GitHub (Jun 23, 2016): Woops, I completely forgot the last case. Sorry, this is not fixed completely :sweat_smile:

claunia commented

2026-01-29 14:21:54 +00:00

@xoofx commented on GitHub (Jun 23, 2016):

Tight footnotes case should be fixed by latest commit 266e0c8

@xoofx commented on GitHub (Jun 23, 2016): Tight footnotes case should be fixed by latest commit 266e0c8

claunia commented

2026-01-29 14:21:57 +00:00

@Jither commented on GitHub (Jun 23, 2016):

That was amazingly fast! 😮 👍

@Jither commented on GitHub (Jun 23, 2016): That was amazingly fast! :open_mouth: :+1:

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/markdig#31