emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Carsten Dominik <dominik@science.uva.nl>
Cc: emacs-orgmode@gnu.org
Subject: Re: footnote questions
Date: Sat, 31 Jan 2009 19:26:31 -0700	[thread overview]
Message-ID: <20524da70901311826h3695cbfseb6438104c3d0754@mail.gmail.com> (raw)
In-Reply-To: <CAF6DA89-0A67-43E7-8BAE-807F55797D5A@uva.nl>

On Sat, Jan 31, 2009 at 09:38, Carsten Dominik <dominik@science.uva.nl> wrote:
> Can you create an example to illustrate the problem?

This test case illustrates some issues with footnotes (apparent bugs,
things to watch out for when making future changes, and desirable
features that Carsten might or might not want to implement).  To test,
place on "hmm" and c-u c-c c-c s.

  1) loses text, deleting it altogether (document 2).
  2) tiny inconsistency: when org-return-follows-link is
     true, RET on definition takes you to ref, but places
     point so that RET again does not get you back.
     (possibly intended behavior.)
  3) does not ignore comments when linting (org inserts
     error).
  4) sort order is wrong if you do take comments into
     account.
  5) moves comments (document 2)
  6) does not keep separate documents separate
     (org-footnote-section is nil because we want them
     separate)
     - moves definitions from one part of outline tree to
       another (note move from document 3).  this is the most
       disconcerting, and feels to me like a bug.  perhaps
       the intent was for all org files to be considered to
       be documents.
     - this variable should perhaps be un-overloaded to allow
       a footnotes section per node.
     - perhaps then the paragraph problem can be easily
       solved as a side-effect
  7) does not renumber numbered references for the author's
     sake (fn:6 before fn:3 in source)
  8) does not renumber for ascii output (fn:1 was deleted but
     is not replaced in ascii output)
  9) does not replace \par with a blank line in ascii output
  10) does not let the author separate paragraphs in defs and
      refill without the paragraphs being merged for the
      author (i.e. blank lines would be nice)
  11) requires attachment to word to avoid refilling causing
      it to seem like a definition (fn:5) -- this one is
      possibly fixed!  Mentioning just in case it is not.

Hope I didn't introduce any rtfm bugs here.  Also hope gmail didn't
introduce transport bugs.  These are not major issues for me
personally.

Hope it helps.

Thanks.


* top
*** another completely separate document -- 3
[1] hi, i am in document 3
\par
this is another paragraph, but you can't
refill it because the author will see it merged.  i'm told
the exported text will be ok.  but it is not.
\\
another way suggested earlier, same result.  exported text
is ok.

dear mr. brown:

oh, here's a footnote def without a ref that i wanted to
keep around:
*** a document -- 1
dear mr. smith:

fn:1 has been deleted

#[fn:2]this is a comment of a previous footnote definition.
#(author deleted ref)

sadfkjn k jthis n klsjan skdljfn akljsdn fklajnsdfklajns
[fn:5]

this[fn:6] is a test[fn:3] of footnote sorting.  recursive
definitions seem to work, so not testing them here.


[fn:3] hmm

[fn:6] after a bunch of deletions, i got here

[fn:5] is something that might be filled to be on the first
column if not attached to a word
*** a completely separate document -- 2
dear mr. jones:

#[3] text.

with manual footnotes[1].

this does, sometimes, happen[2]

[1] not out of order
\par
#[1] text.  here is a comment on this
#footnote.  this gets deleted when sorting.  that feels like
#a bug, even if it isn't.

#here is a comment, placed by an unsuspecting user who
#doesn't know the rules[5].  it gets moved upon sorting.
#arguably, the user should be more careful.  (though
#blank-separated paragraphs would be better if possible.)

#and an even more intransigent user[6].  it gets moved also.
[2] more

-- 
For personal and corporate gain, myalgic encephalomyelitis denialists
are knowingly causing massive suffering and 25-years-early death by
grossly corrupting science.
http://www.meactionuk.org.uk/What_Is_ME_What_Is_CFS.htm

  reply	other threads:[~2009-02-01  2:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-24  5:38 footnote questions Samuel Wales
2009-01-24 11:24 ` Carsten Dominik
2009-01-24 23:55   ` Scot Becker
2009-01-25  7:23     ` Carsten Dominik
2009-01-26  5:26       ` Scot Becker
2009-01-31  5:37   ` Samuel Wales
2009-01-31 16:38     ` Carsten Dominik
2009-02-01  2:26       ` Samuel Wales [this message]
2009-01-25  7:46 ` Carsten Dominik
2009-01-25 17:58   ` Mike Newman
2009-01-27 14:11     ` 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=20524da70901311826h3695cbfseb6438104c3d0754@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=dominik@science.uva.nl \
    --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).