From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: footnote questions Date: Sat, 31 Jan 2009 19:26:31 -0700 Message-ID: <20524da70901311826h3695cbfseb6438104c3d0754@mail.gmail.com> References: <20524da70901232138i4ef4f8d3l399c5c467597ad02@mail.gmail.com> <20524da70901302137u32f8060w16bd975d4479eecd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LTS2c-00017o-UE for emacs-orgmode@gnu.org; Sat, 31 Jan 2009 21:26:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LTS2c-00017G-DD for emacs-orgmode@gnu.org; Sat, 31 Jan 2009 21:26:34 -0500 Received: from [199.232.76.173] (port=54210 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LTS2c-000175-64 for emacs-orgmode@gnu.org; Sat, 31 Jan 2009 21:26:34 -0500 Received: from mail-ew0-f20.google.com ([209.85.219.20]:50187) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LTS2b-0006ev-Ld for emacs-orgmode@gnu.org; Sat, 31 Jan 2009 21:26:33 -0500 Received: by ewy13 with SMTP id 13so1456976ewy.18 for ; Sat, 31 Jan 2009 18:26:31 -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: Carsten Dominik Cc: emacs-orgmode@gnu.org On Sat, Jan 31, 2009 at 09:38, Carsten Dominik 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