From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: Citations, continued Date: Mon, 09 Feb 2015 09:46:35 -0800 Message-ID: <86wq3rrn9g.fsf@berkeley.edu> References: <87vbjmn6wy.fsf@berkeley.edu> <87sieokx8e.fsf@berkeley.edu> <54d04780.cb58460a.5243.2603@mx.google.com> <87h9v3li8t.fsf@berkeley.edu> <54d078ff.b044440a.06ec.3cf6@mx.google.com> <87d25rkmag.fsf@berkeley.edu> <54d1bc7b.c57d440a.3c5d.2dca@mx.google.com> <87vbjh284z.fsf@nicolasgoaziou.fr> <87mw4tk4m7.fsf@berkeley.edu> <87oap7z664.fsf@nicolasgoaziou.fr> <87fvaibr3k.fsf@berkeley.edu> <87y4o9s5qc.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKsQ7-0001aK-LV for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 12:46:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKsQ2-000358-I4 for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 12:46:51 -0500 Received: from plane.gmane.org ([80.91.229.3]:57481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKsQ2-00034y-8k for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 12:46:46 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YKsPy-0006qK-9g for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 18:46:42 +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 ; Mon, 09 Feb 2015 18:46:42 +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 ; Mon, 09 Feb 2015 18:46:42 +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 Tom and all, tsd@tsdye.com (Thomas S. Dye) writes: > IIUC, Org mode citation syntax needs to capture four pieces of > information for an *individual* citation: a =key= into one or more > stores of bibliographic information; a =citation-command= that is > understood by the =citation-style= specified for the document; a > =pre-note= of arbitrary text in any language; and a =post-note= of > arbitrary text in any language. At least, this is how the LaTeX world > accommodates the almost unconstrained and ever-growing variability in > bibliographic styles in the wild. I think the key, pre-note and post-note are common ground, and everyone agrees that they need to be represented in a citation syntax. I am a bit more hesitant about the citation command, though. My reasons for hestitation are the same as other people have expressed here, but I think it might be useful to summarize. As Tom notes, there is basically unlimited complexity in the LaTeX world for citation commands. There's a different subset of commands for every distinction you might want to express in a given style. The trouble is that there is close to zero support for this complexity in the other export formats that Org supports. As far as I am aware (though I could be wrong), HTML, ODT, and other document formats barely even have a way of indicating that a piece of text is a citation. (HTML5 does have a "cite" element, but it seems to be basically an unconstrained semantic element.) Many of us (including me) are exporting to LaTeX, and if that is what you are doing, it is natural to want to have access to all the distinctions that LaTeX provides. But if we try to capture those distinctions in a high-level Org citation syntax, then we have two problems: (a) finding the right syntax to express those distinctions, and (b) exporting citations that make use of those distinctions to non-LaTeX formats, which provide little support for them. The more distinctions we try to capture, the more difficult these problems will be to solve. Thus, I think the right question to ask is: which distinctions are both *simple enough* and *important enough* that they are worth encoding in Org syntax and supporting in non-LaTeX backends? I think that is the right place to draw the line between features of citations that are encoded in `citation syntax proper' vs. `escape hatches' that give more information about how to format a citation in a particular backend. My sense is that a lot of the complexity in LaTeX citations should fall in the latter category, but we need to think more about what falls in the first category. One clear candidate for the first category that I think everyone agrees on is the distinction between in-text vs. parenthetical citations (\citet vs. \citep and similar in LaTeX). For my own case, this is the only distinction I need to be directly expressed in syntax. Nicolas expressed a similar opinion: > It seems to me that :type is a LaTeX-only feature and, as such, should > be handled in "ox-latex". In the general case, I think that Org should > only support inline and parenthesized citations. But in response to a question from Rasmus, Tom also suggested that multi-cites are a candidate, in addition to the in-text/parenthetical distinction: > Yes, I typically use what I call a multicite to get multiple citations > with biblatex. I myself never use these, so I don't understand exactly what would be required to support them properly in non-LaTeX backends, and I can't speak to which category they belong to. Are there other candidates we should discuss? What other distinctions are so important that they are worth figuring out how to express in syntax that can be exported by all backends? As for supporting the `escape hatch' category, it seems that more thought is needed here, too. Right now, the #+ATTR_BACKEND syntax is the only way I know of to specify arbitrary export properties for a piece of Org syntax. But it only applies to greater elements, and Tom at least does not think it is sufficient to only allow specifying the citation command, in particular, in an out-of-line (because greater element) citation definition. So maybe we need some kind of inline syntax for backend-specific properties of citations, perhaps along the lines that Rasmus has suggested. I think this could be a good idea; my only concern is that we make a clear separation between this syntax and the main syntax for citations. There are two reasons for this: if we don't clearly make this separation, then (1) it becomes much harder to figure out and agree on which distinctions should be expressed in `the' citation syntax; and (2) there is a danger that the complexity of backend-specific properties will bleed over into the main citation syntax, which all backends have to support. Best, Richard