commonmark-hs
commonmark-hs copied to clipboard
Footnote in AST lacks index information
The HasFootnote
instance for Pandoc AST ignores the footnote identifiers, and labels:
https://github.com/jgm/commonmark-hs/blob/c9afe7c1ca25dbc1f0580187bb422bd1681ae1b5/commonmark-pandoc/src/Commonmark/Pandoc.hs#L215-L219
And it looks like Pandoc is doing its own state management to compute the identifier, and render the references accordingly. Is storing these footnote identifiers/labels in the Pandoc AST explicitly out of scope?
I'm not sure where we'd store them.
Can we add an extra field to the Note
constructor (which as I understand is used for footnotes exclusively)?
-- | Note <footnoterefname> <footnote>
Note Text [Block]
Just to provide some context: since I need to render in GHCJS, I'm rendering the footnotes by traversing the AST. https://github.com/srid/reflex-dom-pandoc/blob/master/src/Reflex/Dom/Pandoc/Footnotes.hs
You can see how it renders at https://www.srid.ca/1948201.html
In this example, there are four footnotes named 1, 2, 3 and 4. However if you actually look at the source markdown, the footnotes don't use numbers but custom text. I thought it would be nice re-use the same footnote ref as the user provided; but this information is not passed to the Pandoc AST. Adding a field to the Note
constructor is one way to pass it. But then I haven't thought this problem in greater detail considering other pandoc use cases.
Some relevant discussion here: https://github.com/jgm/pandoc/issues/2583
But I generally like to avoid changes to pandoc-types, which are painful for the whole ecosystem (everything has to be changed).
For your purposes, you could create a special instance of IsInline and IsBlock for pandoc, instead of using the one provided in commonmark-pandoc. You could put the contents of each note in a Div and put the label in an attribute of the Div. That would allow you to get it back out again.
That said, it could be worth putting an issue on pandoc-types suggesting this. But only if you're willing to do the work (should the idea be accepted) of modifying all the pandoc code to use the new type!
I suppose the most obvious useful change would be to add an Attr field to the Note constructor.