From: Matthew Lundin <mdl@imapmail.org>
To: "Andreas Röhler" <andreas.roehler@easy-emacs.de>
Cc: emacs-orgmode Mailinglist <emacs-orgmode@gnu.org>
Subject: Re: footnote renumber bug
Date: Thu, 02 Jul 2009 10:48:23 -0500 [thread overview]
Message-ID: <87ab3ngk6w.fsf@fastmail.fm> (raw)
In-Reply-To: <4A4CB3B4.3010405@easy-emacs.de> ("Andreas Röhler"'s message of "Thu, 02 Jul 2009 15:18:44 +0200")
Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
> Karl Maihofer wrote:
>> Andreas Roehler schrieb:
>>
>>> after reopening a file with two footnotes inside,
>>> inserting a third footnote between first and second, it
>>> fails to renumber it.
>>>
>>
>> Did you try the new "C-u C-c C-x f S" feature of the latest git-version?
>>
>
> No. Just check this feature for curiosity, as I dealt with that bug
> at common footnote.el
>
>> Org does not renumber footnotes automatically when they are inserted.
>> You have to use the command above to do that.
>>
>
> IMO a decent program should renumber automatically.
> Patched footnote.el meanwhile does if called with footnote-init.
> Unfortunately your footnote-machine is written fairly different from
> footnote.el.
> Otherwise I'd send a patch.
>
There is nothing preventing a user from using footnote.el (and your
patch) within org mode instead of the built in org-footnote-action.
Simply set up a hook to load footnote-mode for org files.
But the lack of automatic renumbering in org-footnote is *not* a bug.
Unlike footnote.el, org-mode views footnote notation primarily as
markup, not as some form of "final output." The source text simply
contains footnote markup, which can be exported as normalized footnotes.
And of course, at any point, user has the option of normalizing
footnotes in the source text if he/she so desires.
Footnote.el, by contrast, was designed for short email messages in which
there is no distinction between source text and exported text. Though it
serves this limited purpose admirably, it offers only a very rudimentary
numbering system rather than a complete markup solution. For any complex
writing (e.g., a research paper with dozens of footnotes), footnote.el
is well-nigh impossible to use. There are simply too many chances of
broken or mixed up links.
Org-mode's handling of footnotes is considerably more robust. Several
different types of footnote styles are available:
- numbered[1]
- labeled[fn:label]
- inline[fn::Here is an inline footnote.]
Footnotes:
[1] Numbered
[fn:label] Here is a labeled footnote.
------
All of these can be mixed together in the same document. Upon export to
pdf, ascii, or html they will be properly sorted and numbered, but the
labels in the source will remain the same, ensuring that the source text
remains *exactly* as the user wants it to be.
At any point, however, the user can sort and/or renumber the footnotes
in the source text. For instance, the footnotes above can very quickly
and easily converted to the following:
,----
|
| - numbered[1]
|
| - labeled[2]
|
| - inline[3]
|
| Footnotes:
|
| [1] Numbered
|
| [2] Here is a labeled footnote.
|
| [3] Here is an inline footnote.
`----
The key here, however, is that the process is completely under the
user's control. Footnotes will not be sorted or reorganized in the
source text unless the user desires it. In my view, this is the proper
behavior for a robust markup system. The whole point of markup is to
avoid the sorts of automated, global alterations of the source text that
are characteristic of word-processors.
With labeled footnotes in org-footnote, I can rearrange my text and rest
assured that none of my footnote links will be broken. And if I delete a
footnote reference without deleting its corresponding definition (or
vice-versa), org-mode will alert me to the problem when I export or sort
the footnotes.
All this is to explain why the lack of automatic renumbering is *not* a
bug. And of course, anyone who prefers a different behavior can easily
use footnote.el instead.
Regards,
Matt
next prev parent reply other threads:[~2009-07-02 15:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-02 6:55 footnote renumber bug Andreas Roehler
2009-07-02 11:44 ` Karl Maihofer
2009-07-02 13:18 ` Andreas Röhler
2009-07-02 15:48 ` Matthew Lundin [this message]
2009-07-02 16:05 ` Matthew Lundin
2009-07-02 20:09 ` Andreas Röhler
2009-07-02 21:53 ` Matthew Lundin
2009-07-03 8:36 ` Scot Becker
2009-07-03 12:08 ` Andreas Röhler
2009-07-03 14:17 ` Paul R
2009-07-03 14:51 ` Andreas Röhler
2009-07-03 14:42 ` Matthew Lundin
2009-07-03 21:49 ` Carsten Dominik
2009-07-04 8:02 ` Andreas Roehler
2009-07-04 20:30 ` Matthew Lundin
2009-07-05 20:31 ` Carsten Dominik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ab3ngk6w.fsf@fastmail.fm \
--to=mdl@imapmail.org \
--cc=andreas.roehler@easy-emacs.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).