From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: Citation syntax: a revised proposal Date: Sun, 15 Feb 2015 09:05:52 -0800 Message-ID: <877fvjm7f3.fsf@berkeley.edu> References: <87k2zjnc0e.fsf@berkeley.edu> <87386775gc.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN2eb-0007OS-1U for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 12:06:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN2eW-0007CZ-05 for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 12:06:44 -0500 Received: from plane.gmane.org ([80.91.229.3]:55666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN2eV-000786-P7 for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 12:06:39 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YN2eT-0007xD-Nj for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 18:06:37 +0100 Received: from c-67-169-117-151.hsd1.ca.comcast.net ([67.169.117.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Feb 2015 18:06:37 +0100 Received: from richard.lawrence by c-67-169-117-151.hsd1.ca.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Feb 2015 18:06:37 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi Rasmus, Rasmus writes: > 0 > > Parts I like: > > 1) a parenthetical citation for a single work with no prefix and > suffix may be written by just surrounding the key with brackets, > like: [@Doe99]. > 2) an in-text citation for a single work with no prefix and suffix > may be written as a /bare/ key, without brackets, like: @Doe99. > > I recently cracked up something similar for a paper we are working on, and > I think it's nice. I have yet to get the verdict from my coauthor, > though. Cool. :) > Parts that I don't care for: > > [cite: whatever (@Doe99) whatever] > > Not intuitive to me, but I could get used to it. It's not super intuitive to me either, and it just occurred to me yesterday, so maybe there's a better way. The reason I went this way was so that we could represent the difference between parenthetical and in-text citations without moving the cite key and without using different tags (citet: vs. citep:). That makes it easy to write a function that will quickly switch a citation between the two styles, without using the tag to express the difference, which Nicolas was worried would slow down the parser. > Parts I hate: > > The flag is either `@' or `&'. `@' [...] The optional hyphen (`-') > > Too many weird symbols that I won't be able to remember, much less explain > to somebody else. I don't love these either, but I am not sure what a better alternative would be. The `@' is vestigial inspiration from Pandoc, and is used infrequently enough elsewhere in Org syntax that Nicolas at one point said it would be OK performance-wise to have `@key' appear alone in the text. `&' seemed like a natural counterpart for the same reasons, but I agree it isn't terribly intuitive. (Though maybe there's one supporting intuition: `&' is used to introduce keys in URL parameters...) I disagree with you about the hyphen, but I wouldn't use it enough to lobby for it (it is just vestigial Pandoc). If others think we should take it out, that's fine with me. > `%%( ... )'. > > Just too odd. Extensibilty should not be delegated to some weird > construct outside of the element in question. Again, I don't exactly love this either, but I chose this syntax because %%(...) is already used elsewhere in Org to represent embedded s-expressions (notably in timestamps -- see section 8.1 of the manual). %(...) is also used for s-expressions in capture templates, though I'm not sure why the first case uses two `%'s and the second only one. The only reason to use these delimiters is consistency; I'm not opposed to something prettier if there's a better alternative. Keeping this part of the syntax outside the [cite: ...] brackets allows it to be used with bare keys for simple in-text citations, and prevents a further syntactic restriction on prefix/suffix text inside the brackets. I'm not opposed to moving it inside if that seems really important, but these two considerations weigh against it in my opinion. Best, Richard