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 10:07:27 -0800 Message-ID: <873867m4kg.fsf@berkeley.edu> References: <87k2zjnc0e.fsf@berkeley.edu> <87zj8fjdnv.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]:32995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN3cD-0002d7-7y for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 13:08:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN3c7-0003LW-8a for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 13:08:21 -0500 Received: from plane.gmane.org ([80.91.229.3]:59815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN3c6-0003LQ-Tb for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 13:08:15 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YN3c5-00026S-PI for emacs-orgmode@gnu.org; Sun, 15 Feb 2015 19:08:13 +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 19:08:13 +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 19:08:13 +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 Nicolas, Thanks for your comments. A couple of replies follow. Nicolas Goaziou writes: >> The difference between parenthetical and in-text citations is >> expressed using parentheses around the /first/ citation key. A >> parenthetical citation has such parentheses around the first citation >> key; an in-text citation lacks them. (Parentheses around non-initial >> keys are permitted for visual consistency and to keep the grammar >> simple, but have no meaning.) > > I think it would be nicer to differentiate between in-text and > parenthetical citations at the type level, e.g.: > > > [cite: this @key citation is in-text] > [(cite): this @key citation is parenthetical] > > or, as already suggested > > [citet: ...] > [citep: ...] > > I prefer the former. Either of these is fine with me if it is OK with you. I was trying to avoid any variation in the position after `[' to reduce strain on the parser, but if these are simple enough to support without too many false positives, even better. >> This additional information may be supplied following the brackets of >> a citation between the following delimiters: `%%( ... )'. > > As pointed out, this is very odd. But I cannot see any clean solution. As I said in reply to Rasmus, my only reason for this choice was to be consistent with the s-expression syntax in timestamps and capture templates. I am fine with (and even would prefer) something that looks prettier. > However, it would be nice to integrate it somehow with the syntax. Maybe > something like > > [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val] > But I think there are three reasons this does not quite improve on what I proposed: 1) It looks like it only supports properties directed at specific backends. How should users specify custom properties that they want to be handled in multiple backends (by their own filter)? 2) It requires us to decide *now* on conventions for specifying properties to specific backends (and also to build a parser for them, instead of just calling `read'), instead of just using arbitrary s-expressions and seeing what people come up with in the future. (See my reply to Tom for more about how I was thinking this part of the syntax would evolve.) 3) Putting the properties inside the brackets introduces an (admittedly very minor) additional restriction on suffix text, and can't be used with the simple syntax for in-text citations. (See my reply to Rasmus on this point.) That said, I have no objections to doing something like this if we can come to an agreement now about what it should look like. >> ** Outstanding issues >> It seems to me that there are potential problems with the above >> proposal in a number of areas, but I cannot tell how serious they are, >> or what changes (if any) should be made to solve them. I don't >> pretend that this is an exhaustive list: >> 1) *Nesting.* I have favored LaTeX compatibility for in-text >> citations with multiple references; but this means there is no >> way to `nest' citations. Thus, there is no way to express (in >> the main syntax) what Pandoc expresses as: >> @Doe99 [p. 34; see also @DoeRoe2000] >> which renders like: >> Doe (1999, p. 34; see also Doe and Roe 2000) >> Instead, since a citation is in-text or parenthetical as a whole, >> the equivalent in the above syntax >> [cite: @Doe99 p. 34; see also @DoeRoe2000] >> should render like: >> Doe (1999, p. 34), see also Doe and Roe (2000). >> I am not certain if Pandoc-like output is important in this case. >> The few people who commented on this said that it was not. > > AFAIU, when using in-text citation, only the first key is extracted out > of the parenthesis, so > > [cite: @Doe99 p. 34; see also @DoeRoe2000] > > should really render like > > Doe (1999, p. 34; see also Doe and Roe 2000). > > IOW, why do you think that "a citation is in-text or parenthetical as > a whole"? This is a LaTeX compatibility issue, and it is an area where Pandoc departs from LaTeX behavior. If you're a LaTeX user, the natural way to think of the Org syntax you quoted is (I think) as equivalent to one of: \textcites[p. 34]{Doe99}[see also][]{DoeRoe2000} \textcite[p. 34]{Doe99}, \textcite[see also][]{DoeRoe2000} which IIUC both render like Doe (1999, p. 34), see also Doe and Roe (2000). modulo some subtle details about the separator. No one so far has said that they need or want the Pandoc behavior. I personally am fine without it. Best, Richard