For what it's worth, I experimented a bit with changing the rendering pass as part of trying to see how far I could get on the "standard" footnotes style with the current parser. (The answer is: pretty close, but as noted in the discussion in #20, the fact that footnotes are treated as single-block elements means a lot of existing footnotes out there won't parse.) As part of that I confirmed that you can quite easily build backlinks in a renderer given what pulldown-cmark already does.

While it's totally possible to end up with cases where you have a footnote reference with no definition or vice versa, that's an authoring concern (and a place where a renderer could choose to warn!). What's more, that's common in other Markdown implementation.

For example, if you drop this Markdown source into the pandoc demo (or just run pandoc --from markdown --to html5):

A paragraph of text. This demo has a valid footnote reference.[^valid] It also has a invalid footnote reference.[^invalid] And the document also has an orphaned definition, which is not referenced anywhere.

[^valid]: This one is valid.

[^orphan]: This is an orphan footnote definition.

This is the HTML it will generate:

<p>A paragraph of text. This demo has a valid footnote reference.<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a> It also has a invalid footnote reference.[^invalid] And the document also has an orphaned definition, which is not referenced anywhere.</p>
<section class="footnotes" role="doc-endnotes">
<hr />
<ol>
<li id="fn1" role="doc-endnote"><p>This one is valid.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>

There are two extra bits of data required to make that work the same way in a renderer:

a list of footnote definitions which are actually referenced at least once (so e.g. a HashSet seems reasonable here)
a similar list of footnote definitions which actually exist

If you pass both of those to a renderer along with the events, then it's straightforward when emitting the footnote events to do the same thing as pandoc and similar. The existing renderer doesn't support this, of course, and given it simply consumes an Iterator<Item = Event> it’s not clear to me that it could even be made to do so easily, but a fork of that renderer could do it easily enough.

This is actually quite encouraging for my purposes. The only serious blocker I see for conformance to the “standard” footnote format is having a scan/parse mode which supports multiple block children in the footnote and then having that lightly-tweaked renderer available (whether in-tree or not!).

While that unfortunately cannot be implemented backwards-compatibly with the current options (it changes the meaning of an indented block after a footnote definition block), I think it could be implemented with a new option. I am going to see if I can make progress on that. (Could be slow going: I don’t have a ton of time.)

Footnote back-references #142

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions