Bad footnotes when including org files

Bad footnotes when including org files

[Xavier Garrido]

Hi Orgers,

I am having some troubles with several org files that I want to include 
into one general org file. To do that I use the #+INCLUDE: keywords and 
actually, everything is working well until I add some footnotes in both 
files. Let me show you a minimal example where the footnote numbering is 
getting weird

a.org :
-------

* A1
This is A1 section[fn:1].
* A2
This is A2 section.

* Footnotes

[fn:1] this is a footnote in A file.

b.org :
-------

* B1
This B1 section[fn:1].
* B2
This B2 section.

* Footnotes

[fn:1] this a footnote in B file.

ab.org :
--------

#+INCLUDE: "a.org" :minlevel 1
#+INCLUDE: "b.org" :minlevel 1

When I export to LaTeX the latest file, I get two footnotes with the 
same number. The problem can be solved by changing the label of the 
second footnote to [fn:2] but it means that I have to reorganize and 
reorder footnotes within all the org files I will include. I am 
wondering if it is possible to run, for example, 
=org-footnote-renumber-fn:N= function when including files in such way 
the user will not have to take care footnote labels.

Thanks for your help,
Xavier

Re: Bad footnotes when including org files

[James Harkins]

Xavier Garrido <xavier.garrido <at> gmail.com> writes:

> 
> Hi Orgers,
> 
> I am having some troubles with several org files that I want to include 
> into one general org file. To do that I use the #+INCLUDE: keywords and 
> actually, everything is working well until I add some footnotes in both 
> files. Let me show you a minimal example where the footnote numbering is 
> getting weird
> 
> When I export to LaTeX the latest file, I get two footnotes with the 
> same number. The problem can be solved by changing the label of the 
> second footnote to [fn:2] but it means that I have to reorganize and 
> reorder footnotes within all the org files I will include. I am 
> wondering if it is possible to run, for example, 
> =org-footnote-renumber-fn:N= function when including files in such way 
> the user will not have to take care footnote labels.

I had exactly this problem in a big project. Poking around the customization
group org-footnote, I found:

Org Footnote Auto Label: Value Menu Create a random label
   State: SAVED and set.
   Non-nil means define automatically new labels for footnotes.
   Possible values are:
   
   nil        Prompt the user for each label.
   t          Create unique labels of the form [fn:1], [fn:2], etc.
   confirm    Like t, but let the user edit the created value.
              The label can be removed from the minibuffer to create
              an anonymous footnote.
   random	   Automatically generate a unique, random label.
   plain      Automatically create plain number labels like [1].

I switched to random labels, and no problem since then.

I don't find any evidence of a function that will automatically switch
existing footnotes to random IDs, though, and I'm afraid I'm short of time
this morning. It should be possible, but I guess nobody has done it.

But, do set the custom var to use random labels. It will prevent the problem
for all new footnotes.

hjh

Re: Bad footnotes when including org files

[Xavier Garrido]

Hi James,

Thanks for your answer. Maybe I will try your solution. Otherwise I will 
run a "before-parse-hook" to change fn:XX to something unique (by adding 
buffer name for example.

Thanks again,
Xavier

Le 16/03/2014 02:32, James Harkins a écrit :
> Xavier Garrido <xavier.garrido <at> gmail.com> writes:
>
>>
>> Hi Orgers,
>>
>> I am having some troubles with several org files that I want to include
>> into one general org file. To do that I use the #+INCLUDE: keywords and
>> actually, everything is working well until I add some footnotes in both
>> files. Let me show you a minimal example where the footnote numbering is
>> getting weird
>>
>> When I export to LaTeX the latest file, I get two footnotes with the
>> same number. The problem can be solved by changing the label of the
>> second footnote to [fn:2] but it means that I have to reorganize and
>> reorder footnotes within all the org files I will include. I am
>> wondering if it is possible to run, for example,
>> =org-footnote-renumber-fn:N= function when including files in such way
>> the user will not have to take care footnote labels.
>
> I had exactly this problem in a big project. Poking around the customization
> group org-footnote, I found:
>
> Org Footnote Auto Label: Value Menu Create a random label
>     State: SAVED and set.
>     Non-nil means define automatically new labels for footnotes.
>     Possible values are:
>
>     nil        Prompt the user for each label.
>     t          Create unique labels of the form [fn:1], [fn:2], etc.
>     confirm    Like t, but let the user edit the created value.
>                The label can be removed from the minibuffer to create
>                an anonymous footnote.
>     random	   Automatically generate a unique, random label.
>     plain      Automatically create plain number labels like [1].
>
> I switched to random labels, and no problem since then.
>
> I don't find any evidence of a function that will automatically switch
> existing footnotes to random IDs, though, and I'm afraid I'm short of time
> this morning. It should be possible, but I guess nobody has done it.
>
> But, do set the custom var to use random labels. It will prevent the problem
> for all new footnotes.
>
> hjh
>
>

Re: Bad footnotes when including org files

[Nicolas Goaziou]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

Hello,

Xavier Garrido <xavier.garrido@gmail.com> writes:

> Thanks for your answer. Maybe I will try your solution. Otherwise
> I will run a "before-parse-hook" to change fn:XX to something unique
> (by adding buffer name for example.

We could do it by default.

One problem is that INCLUDE keyword is a very simple feature. For
example, if you include two files in a row and the first one ends with
a footnote section, the other one will be included in that section and,
therefore, not exported. So if we start to make it smart, we could be
tempted to add too many other checks.

Anyway, here's a patch for that.

WDYT?


Regards,

-- 
Nicolas Goaziou

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-Make-footnotes-file-specific-when-including-Org-f.patch --]
[-- Type: text/x-diff, Size: 3411 bytes --]

From 2a22d4dc3beb300094c9ee28158f227dbf467cda Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Wed, 26 Mar 2014 15:34:59 +0100
Subject: [PATCH] ox: Make footnotes file specific when including Org files

* lisp/ox.el (org-export-expand-include-keyword,
  org-export--prepare-file-contents): Make footnotes file specific
  when including Org files.

http://permalink.gmane.org/gmane.emacs.orgmode/83606
---
 lisp/ox.el | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 9f77af4..cf70643 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -3279,7 +3279,9 @@ with their line restriction, when appropriate.  It is used to
 avoid infinite recursion.  Optional argument DIR is the current
 working directory.  It is used to properly resolve relative
 paths."
-  (let ((case-fold-search t))
+  (let ((case-fold-search t)
+	(file-prefix (make-hash-table :test #'equal))
+	(current-prefix 0))
     (goto-char (point-min))
     (while (re-search-forward "^[ \t]*#\\+INCLUDE:" nil t)
       (let ((element (save-match-data (org-element-at-point))))
@@ -3349,13 +3351,16 @@ paths."
 		 (with-temp-buffer
 		   (let ((org-inhibit-startup t)) (org-mode))
 		   (insert
-		    (org-export--prepare-file-contents file lines ind minlevel))
+		    (org-export--prepare-file-contents
+		     file lines ind minlevel
+		     (or (gethash file file-prefix)
+			 (puthash file (incf current-prefix) file-prefix))))
 		   (org-export-expand-include-keyword
 		    (cons (list file lines) included)
 		    (file-name-directory file))
 		   (buffer-string)))))))))))))
 
-(defun org-export--prepare-file-contents (file &optional lines ind minlevel)
+(defun org-export--prepare-file-contents (file &optional lines ind minlevel id)
   "Prepare the contents of FILE for inclusion and return them as a string.
 
 When optional argument LINES is a string specifying a range of
@@ -3369,7 +3374,12 @@ headline encountered.
 
 Optional argument MINLEVEL, when non-nil, is an integer
 specifying the level that any top-level headline in the included
-file should have."
+file should have.
+
+Optional argument ID is an integer that will be inserted before
+each footnote definition and reference if FILE is an Org file.
+This is useful to avoid clashes when more than one Org file with
+footnotes is included in a document."
   (with-temp-buffer
     (insert-file-contents file)
     (when lines
@@ -3428,6 +3438,20 @@ file should have."
 	       (org-map-entries
 		(lambda () (if (< offset 0) (delete-char (abs offset))
 			(insert (make-string offset ?*)))))))))))
+    ;; Append ID to all footnote references and definitions, so they
+    ;; are file specific and cannot collide with other included files.
+    (goto-char (point-min))
+    (while (re-search-forward org-footnote-re nil t)
+      (let ((reference (org-element-context)))
+	(when (memq (org-element-type reference)
+		    '(footnote-reference footnote-definition))
+	  (goto-char (org-element-property :begin reference))
+	  (forward-char)
+	  (let ((label (org-element-property :label reference)))
+	    (cond ((not label))
+		  ((org-string-match-p "\\`[0-9]+\\'" label)
+		   (insert (format "fn:%d-" id)))
+		  (t (forward-char 3) (insert (format "%d-" id))))))))
     (org-element-normalize-string (buffer-string))))
 
 (defun org-export-execute-babel-code ()
-- 
1.9.1

Re: Bad footnotes when including org files

[Xavier Garrido]

Hi Nicolas,

Le 26/03/2014 15:41, Nicolas Goaziou a écrit :
> Hello,
>
> Xavier Garrido <xavier.garrido@gmail.com> writes:
>
>> Thanks for your answer. Maybe I will try your solution. Otherwise
>> I will run a "before-parse-hook" to change fn:XX to something unique
>> (by adding buffer name for example.
>
> We could do it by default.
>
> One problem is that INCLUDE keyword is a very simple feature. For
> example, if you include two files in a row and the first one ends with
> a footnote section, the other one will be included in that section and,
> therefore, not exported. So if we start to make it smart, we could be
> tempted to add too many other checks.
>
> Anyway, here's a patch for that.
>
> WDYT?
>

Applied, tested and it works like a charm. I still have some issues with 
a very big "book" I am writing but at least on the small example I sent 
it solves the issues.

Thanks a lot,
Xavier

Re: Bad footnotes when including org files

[Nicolas Goaziou]

Hello,

Xavier Garrido <xavier.garrido@gmail.com> writes:

> Applied, tested and it works like a charm. I still have some issues
> with a very big "book" I am writing but at least on the small example
> I sent it solves the issues.

I applied the patch to master.


Regards,

-- 
Nicolas Goaziou