Footnote in AST lacks index information

[srid]

The HasFootnote instance for Pandoc AST ignores the footnote identifiers, and labels:

commonmark-hs/commonmark-pandoc/src/Commonmark/Pandoc.hs

Lines 215 to 219 in c9afe7c

	instance (Rangeable (Cm a B.Inlines), Rangeable (Cm a B.Blocks))
	=> HasFootnote (Cm a B.Inlines) (Cm a B.Blocks) where
	footnote _num _lab _x = mempty
	footnoteList _xs = mempty
	footnoteRef _num _lab contents = B.note <$> contents

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?

[jgm]

I'm not sure where we'd store them.

[srid]

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.

[jgm]

Some relevant discussion here:
jgm/pandoc#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.

[jgm]

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!

[jgm]

I suppose the most obvious useful change would be to add an Attr field to the Note constructor.