Multiple calls to the same footnote

[Omikhleia]

Just some ideas following a personal discussion.

(In Djot at least) nothing forbids a writer to call the same footnote reference multiple times.

There are some cases where this could be useful (ex. a list of items, where several call for the same details in a common footnote). One could argue that's it's only an "acceptable" solution if the calls are on the same page (or not to far away...), but that should be an author decision, not a technical limitation.

Currently, we do not reject multiple calls to the same note, but:

• A warning is issued (Duplicate label '...': this is possibly an error)
• Two footnotes are produced (with same content... and same cross-reference label, so only the latest will be honored if the footnote is later referred by its identifier).

It would be possible to support this is use case:

• On first occurrence, spit out a complete footnote indeed.
• On later occurrences, only spit out a footnote reference call (to the first call, via cross-refs)

One problem however is that the footnote reference call are not the same between SILE's regular footnote package (footnotemark) and the resilient footnote package (style-aware footnote:reference) -- They are not honoring the same "public" API here :)

[Omikhleia]

Additional notes:

(Pandoc AST): Simply not doable from the AST (notes already resolved) = See also jgm/pandoc#1603 (open issue, as of this date) → We currently get the same note incremented but repeated.

(Markdown): Notes are collected and resolved in the lunamark reader, and passed to writer.note as parsed blocks = not doable without modifying (our copy of) lunamark -- Deemed an overkill for the purpose. → We currently get the same note incremented but repeated.

(Djot): Our renderer honors the #id (and defaults for it to the note identifier), so we could track these, but as noted above

• With SILE core footnotes, \footnotemark uses the current note counter, so can't be re-applied arbitrarily
• With resilient footnotes, \footnote:reference behaves identically (though we would be in a position to refactor/extend it)...

For explicitly marked footnotes with a symbol, rather than numbered (= e.g. { mark="†" } ) we could however do it, but this does sounds to be a weird edge case:

--- a/packages/markdown/commands.lua
+++ b/packages/markdown/commands.lua
@@ -557,6 +557,7 @@ Please consider using a resilient-compatible class!]])
     end
   end, "Link in Markdown (internal)")
 
+  self._notes = {}
   self:registerCommand("markdown:internal:footnote", function (options, content)
     if not self.hasCommandSupport.footnote then
       -- The reasons for NOT loading a package for this high-level structure
@@ -566,7 +567,12 @@ Please consider using a resilient-compatible class!]])
       SU.warn("Trying to enforce fallback for unavailable \\footnote command")
       self:loadAltPackage("resilient.footnotes", "footnotes")
     end
+    if options.id and self._notes[options.id] and options.mark and self.hasCommandSupport["footnote:marker"] then
+      SILE.call("style:apply:number", { name = "footnote-reference-symbol", text = options.mark })
+      return
+    end
     if options.id then
+      self._notes[options.id] = true
       content = {
         createCommand("label", { marker = options.id }),
         subContent(content)

A first footnote[^note] is here.

Anoter footnote[^note] referencing the same note identifier.

{mark="†"}
[^note]: Am I duplicated now?

This is not totally dumb (exact same symbol for exact same note = the duplication would look even more wrong than with regular (numbered) notes...

The above is not sufficient however, we'd still get into trouble if the note occurs in a header, caption, etc. (all elements that may be used in a ToC or in running header), but this is a broader issue (cancellation of "fragile" commands such as footnotes, label references etc. in such cases is not totally working with the "workarounds" currently in place). It would have to be addressed first....

Overall, not sure we want to move forward here for now...