From: Carsten Dominik <carsten.dominik@gmail.com>
To: Matthew Lundin <mdl@imapmail.org>
Cc: emacs-orgmode Mailinglist <emacs-orgmode@gnu.org>,
Andreas Roehler <andreas.roehler@online.de>
Subject: Re: footnote renumber bug
Date: Sun, 5 Jul 2009 22:31:09 +0200 [thread overview]
Message-ID: <2405F8E3-A2F6-4088-857E-6CC7A2DC4BC3@gmail.com> (raw)
In-Reply-To: <87zlbkqjgw.fsf@fastmail.fm>
On Jul 4, 2009, at 10:30 PM, Matthew Lundin wrote:
> Andreas Roehler <andreas.roehler@online.de> writes:
>> Carsten Dominik wrote:
>>>
>>> On Jul 2, 2009, at 8:55 AM, Andreas Roehler wrote:
>>>
>>
>>> Org did not implement automatic renumbering and sorting because
>>> it makes less sense to do so if footnotes are inline, or named
>>> and referenced multiple times.
>>>
>> IMHO renumbering should be able to cope with all this circumstances.
>> With named footnotes "renumbering" might no longer be the appropriate
>> term then...
>
> I believe already Carsten built this feature into
> org-footnote-auto-adjust. If turned on, it automatically renumbers
> footnotes with automatic labels (fn:1) and sorts footnotes with custom
> labels. Also, in addition to nil and t, you can also set the
> variable to
> "sort" or "renumber". E.g.,
>
> (setq org-footnote-auto-adjust 'sort)
>
> With this setting, org-mode will still automatically sort your
> footnotes
> in the order in which they appear in the document but will not
> renumber
> them.
>
> (BTW, thanks, as always, Carsten for such a flexible implementation of
> this new feature. Astonishing!)
>
>>> I can see that, when using footnotes in an isolated
>>> small document and automatic footnote lable generation,
>>> automatic renumbering and sorting is indeed useful.
>>>
>>> In this case, you could fall back to footnote.el.
>>> However, Org does internally have functions to sort
>>> and renumber footnotes, so there is no reason why we could
>>> not call them after generating or deleting a note.
>>> Lets see ... OK, in the latest git version of Org, use
>>>
>>> (setq org-footnote-auto-adjust t)
>>>
>>
>> My suggestion:
>> Make it cope with inline, named and referenced multiple notes;
>> then set it to t by default.
>
> I tested it, and it already copes with a mix of numbered, inline, and
> named footnotes. Here are some settings that might be used to provide
> maximum flexibility for working with all sorts of footnote labels:
>
> (setq org-footnote-auto-label 'confirm ;; [1]
> org-footnote-auto-adjust t ;; [2]
> org-footnote-define-inline nil) ;; [3]
>
> [1] Offers a prompt with automatic labels, e.g. fn:1, but gives the
> user
> the option of changing the label or leaving it blank for an inline
> footnote.
>
> [2] From my preliminary testing, I discovered that setting this to t
> means that org-mode will (a) automatically renumber footnotes with the
> fn:1 style notation; (b) automatically sort both named and numbered
> footnotes to match their order in the text; and (c) leave inline
> footnotes alone.
>
> [3] This is the default setting, but I included it here for the
> purposes
> of example.
>
> - Note: If one uses inline footnotes with automatic labels[fn:1:
> Such as this footnote], the labels will be renumbered to match
> their order in the text. Obviously, sorting would be irrelevant
> in
> such an instance.
>
> I have mixed feelings about turning on automatic renumbering by
> default.
> I think the key issue would be whether doing so would cause any
> problems
> or unnecessary overhead for people who do not use auto labels or who
> prefer unlabeled inline footnotes. Although it's probably trivial, if
> automatic renumbering were the default behavior, org-footnote-action
> would alter the buffer globally without the user explicitly requesting
> or permitting it---or even being aware of it.
I am hesitating too. The reason for this is that Org can collect
footnotes into a special section, or leave them locally.
Before Org kicks the the footnotes into some place which
may or may not be the place a user intended, it is OK to learn
about the options and set them.
Maybe a FAQ entry about these issues would be helpful.... ?
- Carsten
prev parent reply other threads:[~2009-07-05 20:31 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
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 [this message]
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=2405F8E3-A2F6-4088-857E-6CC7A2DC4BC3@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=andreas.roehler@online.de \
--cc=emacs-orgmode@gnu.org \
--cc=mdl@imapmail.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).