joostkremers / pandoc-mode

An Emacs minor mode for interacting with Pandoc.
https://joostkremers.github.io/pandoc-mode/
174 stars 14 forks source link

Footnote mismatch when using a master file with @@include #76

Open adql opened 6 years ago

adql commented 6 years ago

When writing a document with a master file which includes more than one @@include directives, each file would (in normal usage) have footnotes numbering 1, 2, 3, ... . This results in mismatch in footnotes in the final result since the text from the files is included verbatim and only then processed in the master file.

That is, if two included files both have a footnote [^1], the final result will have the text of the second footnote appear in both of them (I tested LaTeX and html5 outputs with the same result).

This of course results from markdown-mode's footnote mechanism (C-c C-s f) which sets a counter to begin with the highest footnote number +1 in the visited file. Therefore a workaround is to manually change the first footnote entered in a new file from [^1] to e.g. [^101], [^201], [^301], ..., corresponding to the ordering of the @@includeed files to follow a logic of chapters or similarly.

It would be useful to have pandoc-mode automate such a process.

pandoc-mode 2.20 on Emacs 25.3.2.

joostkremers commented 6 years ago

Note that Pandoc has an option, file-scope, that can also be used to resolve this issue. Using file-scope, Pandoc is able to distinguish between footnote [^1] in file A and footnote [^1] in file B. However, this option has some further consequences (it applies to links in general, and links across files become impossible, and I think it also has consequences if you use filters), so it may not be the right solution in every case.

So, in principle, it would be nice if footnote numbering could be adjusted automatically, but I'm reluctant to make it dependent on other files (and thus to fully automate it), because I fear that could lead to problems. What happens, for example, if you rearrange your chapters, split chapters into two, or join two chapters? Suppose you have a master file with six @@includes corresponding to a chapter each, and you decide to join two chapters. Then chapter 6 becomes chapter 5, but it will still have footnote numbers starting with 601. If you then add a new file, it will be the sixth @@include (because you removed an @@include) so pandoc-mode would assign 601 as the first footnote number, which wouldn't be right.

Or if you add a chapter in the middle, say you have six chapters and add one between the second and third. Then the new file would be the third @@include and consequently have 301 as its first footnote, but that number already exists in the old chapter 3, which is now chapter 4.

So my suggestion would be the following: if pandoc-mode is activated alongside markdown-mode, and a master file is set for the current file, the behaviour of C-c C-s f is changed so that if no footnotes have been defined yet, the user is asked for an initial footnote number. That way, you can specify a different number for each file and you can make sure no conflicts arise.

adql commented 6 years ago

I agree, it's a difficult one to find an ideal solution. file-scope would indeed be problematic since in documents of such scale it's typical to reference to other chapters etc.

I thought of the idea of parsing each file when it's @@includeed so that each footnote received a preceding numbering which increments through each @@include. Thus footnotes in the first file would be parsed e.g. [^101], [^102], …, in the second file [^201], [^202], etc. It would not change the files themselves but only the included text which is then piped to Pandoc.

However, I can think of two difficulties here: first, if the user uses non-standard numbering or even texts, then it's hard to expect the result. A solution would be to parse only standard incrementally numbered footnotes.
A second, more serious problem is that linking to footnotes in other files would be just as impossible as with the file-scope option. This sounds difficult to solve since changing the numbering would have to be consistent through different included files.

Probably your suggestion would be the most reasonable since it simply automates what the user currently has to do manually anyway.