From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: Citations, continued Date: Sun, 08 Feb 2015 11:50:38 +0100 Message-ID: <87vbjcoewx.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> <87d25kpxap.fsf@pank.eu> <87k2zsso3w.fsf@nicolasgoaziou.fr> 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]:56562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKPS0-0002Ml-Cz for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 05:50:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKPRx-0006hw-5h for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 05:50:52 -0500 Received: from plane.gmane.org ([80.91.229.3]:56944) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKPRw-0006hQ-Qf for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 05:50:49 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YKPRu-0002iU-3T for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 11:50:46 +0100 Received: from tsn109-201-152-245.dyn.nltelcom.net ([109.201.152.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Feb 2015 11:50:46 +0100 Received: from rasmus by tsn109-201-152-245.dyn.nltelcom.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 08 Feb 2015 11:50:46 +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, Thanks for the quick reply. A very colorful (in Gnus at least) reply follows. >>> 1. [cite:@item1] says blah. >>> 2. [cite:@item1: p. 30] says blah. >> >> Why is "p." stripped here? > > I don't understand. Anyway, I now suggest This is what I'm talking about: >>> 2. [cite:@item1: p. 30] says blah. >>> ... ^^^^ >>> 2. Doe (2005, 30) says blah. >>> ^^^ >>> 3. [cite:@item1: p. 30, with suffix] says blah. >>> 4. [cite:@item1: -@item2 p. 30; see also @item3] says blah. >> >> If item{1,2} have the same author biblatex[-chicago?] is smart enough to >> compress it to "author (year1, year2)". So this example seems like a >> downgrade if "-" is required to get the suggested output. > > [@item1 -@item2 p. 30] > > Downgrade is a bit strong. If I have to think about the /formatting/ out output rather than the /contents/ downgrade is not too strong (IMO). In the example above, why not [@item1 @item2 p. 30]? Another issue is that it's not transpose-words safe. E.g. this output seems bad: [-@k1 @k2 30] => Y1 A2 (Y2, 30). >>> 5. A citation group [cite:: see @item1 p. 34-35; also @item3 chap. 3]. >> >> Why is chap. *not* stripped here? > > I do not understand either. Compare to example 1 where p. is stripped. Here chap. is /not/ stripped. >>> 5. A citation group (see Doe 2005, 34–35; also Doe and Roe 2007, chap. 3). >> Where does suffix and locator end here. E.g. what is the output of >> >> [cite:: @item1 33, pp. 35-37, and nowhere else]. > > [cite: @item1 pp. 33, 35-37, and nowhere else] > > suffix and locator are merged (AFAIU, in practice, there is no > distinction between locator and suffix): "pp. 33, 35-37, and nowehere > else". But in your previous examples data is stripped from the locator. If there's no difference I think it would be better to not talk about this locator 'cause it's extremely confusing. >>> 9. Citation with suffix only [cite:: @item1 and nowhere else]. >> >> How do I know this is a suffix? Is locator a regexp like >> \`[p\.0-9 ]+? > > See above. >> What is [cite:@K s. 12] or [cite:@K side.? 12]? > > See above. See also above. From you explanation I would guess that at least these two examples are wrong. Is that correct? >>> 2. [cite:@item1: p. 30] says blah. >>> 2. Doe (2005, 30) says blah. >>> 3. [cite:@item1: p. 30, with suffix] says blah. >>> 3. Doe (2005, 30, with suffix) says blah. >> What if I need several text cite keys. Say @K{1,2} is the same author A, >> and @K3 is B. Then [cite:@K1,@K2,@K3] should/could be something like >> A (Y1, Y2), and B (Y3). How do I express this? > > Since A and B do not appear in the same parenthesis, two citations are > needed: > > [@K1 -@K2], and [@K3] This is a minor downgrade from biblatex. The year thing is worse. >> Some comments. >> >> 1. Am I supposed to distinguish between a text citations and parenthesis >> citation based on a single ":"? That's hard. Why not distinguish >> based on the initial label? E.g. {textcite, parentcite} or {citet, >> citep}. > > In fact, you're right, we don't need the colon, hence my other proposal. This is much better. >> 2. The idea of locator /and/ suffix is confusing. The fact that your >> examples suggest seemingly random dropping of data from locator makes >> me want to avoid it even more. It's a 'can of worms' to use a >> frequently emerging expression from this list. > > Again, there's no real need to extract a locator. At least, not at the > parser level. Let's stop talking about this locator then. It appears nowhere else in LaTeX or Org documentation. >> 5. . . . Yet I still don't know how to get A1 (PRE Y2) with the above. >> Is the benchmark correct? > > You can't. Is this needed? It's not unheard of. I have used it in the past. In LaTeX it's something like: \citet[C]{k} → A (Y, C) \citet[B][]{k} → A (B, Y) \citet[B][C]{k} → A (B, Y, C) >> If parsing speed is key here I think that >> [citet: pre1 @k1 post1; pre2 @k2 post2] and [citep: pre1 @k1 post1; pre2 @k2 post2] >> are clearer solutions. But this is clearly closer to a LaTeX than >> pandoc. > > If "A1 (PRE Y2)" is really needed, then yes, I think that's good enough. > Otherwise I think [@k1] is terse and nice. It's nice. @k1 / [pre @k1 post] for text and (pre @k1 post) for parentheses expressions is nicer, but that's details. I trust your judgment on the technical merit of one idea versus the next. Thanks, Rasmus -- El Rey ha muerto. ¡Larga vida al Rey!