From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Footnotes and org-export, revisited Date: Sat, 3 Jan 2009 09:17:08 +0100 Message-ID: References: <3051994A-5B12-4497-AB58-BAF9A70020D8@uva.nl> <5E498B46-C3D1-4BF6-AD0E-4F416CD72EE9@uva.nl> Mime-Version: 1.0 (Apple Message framework v929.2) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJ1h9-00018J-4L for emacs-orgmode@gnu.org; Sat, 03 Jan 2009 03:17:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJ1h7-000187-9T for emacs-orgmode@gnu.org; Sat, 03 Jan 2009 03:17:17 -0500 Received: from [199.232.76.173] (port=51620 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJ1h7-000184-4J for emacs-orgmode@gnu.org; Sat, 03 Jan 2009 03:17:17 -0500 Received: from mx20.gnu.org ([199.232.41.8]:37475) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LJ1h6-0006kQ-Mk for emacs-orgmode@gnu.org; Sat, 03 Jan 2009 03:17:16 -0500 Received: from mail-ew0-f13.google.com ([209.85.219.13]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJ1h5-00021K-7V for emacs-orgmode@gnu.org; Sat, 03 Jan 2009 03:17:15 -0500 Received: by ewy6 with SMTP id 6so7364437ewy.18 for ; Sat, 03 Jan 2009 00:17:12 -0800 (PST) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Matthew Lundin Cc: emacs-orgmode@gnu.org Hi Matt, thanks for this much needed feedback. I was already working into the direction of some of your proposals, but certainly not all. On Jan 2, 2009, at 4:10 PM, Matthew Lundin wrote: > > Hi Carsten, > > Carsten Dominik writes: > >> Hi Matt, >> >> the bug is fixed now, thanks for the report. >> >> Also, you can set org-footnote-section to nil >> if you want non-inline footnotes to be defined >> in the outline node where they are referenced, instead >> of a special outline node "Footnotes". > > Thanks for alerting me to this option. I'm assuming that > org-footnote-section is meant to control the initial placement of > non-inline footnotes and not their placement after sorting or > normalizing. (When I sort or normalize the footnotes, they are placed > at the end of the last section of the outline.) Would it be possible > to have this option also control the placement of sorted footnotes? > I.e., during sorting or normalizing, footnotes would be placed in the > outline section corresponding to their reference. Yes, this would be much more consistent. Now it does this, sorting will move each definition to the entry of the first reference, if org-footnote-section is nil. > > > A few other *wishlist* items/ideas regarding this wonderful addition > to org-mode. Please feel free to consider or disregard these ideas at > your leisure. > > A. For visibility in org-mode files, it might be nice if there were a > special face for the footnote markup. One of the things I really like > about AUCTeX is its nice color highlighting of macros such as > footnotes. (And, of course, I like the same thing about hyperlinks in > org-mode!) Done. > > > B. Also for visibility in org-mode files, it might nice to have the > option of making the content of inline footnotes invisible (similar to > AUCTeX macro folding). For instance, if this option were turned on... > > Here is a footnote.[fn:: Footnote text.] > > would appear as... > > Here is a footnote.[fn] > > Perhaps then a function/keybinding could allow editing the footnote > text in the minibuffer, similar to C-c C-l for links. I agree that this would be nice, but multiline font-lock (which would be needed to do this) is relatively fragile. I believe John & CO have a better font-lock scheme in muse wich does handle this stuff better, but I would need time to study how tis exactly works. So no for now. > C. The in-buffer conversion from inline footnotes to numbered > footnotes is fantastic for creating readable documents. It might be a > nice feature to have a similar conversion in reverse: that is, from > non-inline footnotes to inline footnotes? As far as I understand it, > the pre-process hook for org-latex-export already does something > similar (line 1310). Yes. Footnote export to LaTeX is actually silly. It first extracts all notes to the end of te buffer during preprocessing, and then moves them back during export :-) > It converts regular footnotes like this: > > Here is a footnote.[1] > > [1] Footnote text. > > to... > > Here is a footnote.\footnote{Footnote text.} > > I wonder whether something similar could be available in org-mode > buffers--i.e., conversion to the inline [fn:: Footnote text] instead > of the LaTeX macro. > > The chief rationale for such a feature would be to make footnotes > portable from one org-mode file to another. Isn't the new sorting good enough for this? I am uncomfortable with letting a program doing so much complex editing. I think it will break too often. > Let's say I have a lot of > numbered/labeled footnotes defined under an outline heading titled > "Footnotes." Let's say, additionally, that I'd like to copy one > subtree of text from that file to a different file, but that I want to > ensure that only those footnotes referred to in the subtree are > copied. Being able to convert all footnotes in the file to inline > footnotes would ensure that the correct footnotes are > attached/included. Then, of course, it would be easy to normalize > footnotes once again in both files. > > D. When normalizing inline footnotes, it would be nice if there were > an option for automatically filling the resulting paragraphs and > footnotes. Currently the following source: This option does now exist: org-footnote-fill-after-inline-note-extraction The only problem s that while Org-s fill-paragraph does the right thing under most circumstances, there are cases where it is imperfect or even breaks things. Try it, mostly it should work. In fact, this is relevant only for normalizing in the buffer, and for the ASCII backend. The other backends do not care. Thanks, please keep testing and the feedback coming. - Carsten