From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: Citations, continued Date: Mon, 09 Feb 2015 21:13:56 +0100 Message-ID: <874mqug7wb.fsf@gmx.us> 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> <86wq3rrn9g.fsf@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKuih-0003wF-2R for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 15:14:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKuic-0001PB-Ty for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 15:14:11 -0500 Received: from plane.gmane.org ([80.91.229.3]:38322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKuic-0001Op-Jp for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 15:14:06 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YKuiY-0002fP-Jv for emacs-orgmode@gnu.org; Mon, 09 Feb 2015 21:14:02 +0100 Received: from tsn109-201-152-16.dyn.nltelcom.net ([109.201.152.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Feb 2015 21:14:02 +0100 Received: from rasmus by tsn109-201-152-16.dyn.nltelcom.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Feb 2015 21:14:02 +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 Richard Lawrence writes: > 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. False. There has been discussions as to whether prenote should be included for inline citations. > 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. Ideally we find TOOL that can handle this. Worse case: bibtex.el, but hopefully something less bare-bone, that knows about styles would be great. E.g. "Zotero for html" or similar. > 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. I don't know. If you think of a type as a receipt it makes sense to allow it to some extend, I guess. Most LaTeX "receipts" very easy to use 'cause somebody took care of the details. > 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: Multicite is pretty easy. A couple of days ago I showed that you can even do it with the current link syntax. Examples: \textcites(pre-both)(post-both)[pre1][post1]{bohringer14}[pre2][post2]{davis14} → pre-both Böhringer et al. (pre1 2014, post1) and Davis and Schiraldi (pre2 2014, post2), post-both \parencites(pre-both)(post-both)[pre1][post1]{bohringer14}[pre2][post2]{davis14} → (pre-both pre1 Böhringer et al. 2014, post1; pre2 Davis and Schiraldi 2014, post2, post-both) But multicite is surely a ox-latex feature, but it's just a convenience wrapper around normal cite commands which can be constructed using primitives, namely :author, :year :pre and :post. You could imagine something like [cite: pre-both; pre1 @k1 post1; pre2 @k2 post2; post-both] Which could be simplified to [cite: pre-both pre1 @k1 post1; pre2 @k2 post2 post-both] > 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. >From a user perspective, links take a backend argument. > 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. Those are indeed valid concerns. One reason why I like :type is that all complexity is hidden away somewhere else. Much like links. This may not be a good thing. I'm heating up on (my interpretation) of Nicolas idea: [cite: pre-both; pre1 @k1 post1; pre2 @k2 post2; post-both] It's still an improvement (though small) over links, and you might still get one "free" type which can be expressed as [@k]. —Rasmus -- What will be next?