From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Citations, continued Date: Sun, 08 Feb 2015 13:36:07 +0100 Message-ID: <87bnl4shqg.fsf@nicolasgoaziou.fr> 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> <87vbjcoewx.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKR4v-0007ml-Ru for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 07:35:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YKR4s-0003wF-M4 for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 07:35:09 -0500 Received: from relay5-d.mail.gandi.net ([2001:4b98:c:538::197]:34148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YKR4s-0003jn-Dz for emacs-orgmode@gnu.org; Sun, 08 Feb 2015 07:35:06 -0500 In-Reply-To: <87vbjcoewx.fsf@gmx.us> (rasmus@gmx.us's message of "Sun, 08 Feb 2015 11:50:38 +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: Rasmus Cc: emacs-orgmode@gnu.org Rasmus writes: >>>> 2. [cite:@item1: p. 30] says blah. >>>> ... ^^^^ >>>> 2. Doe (2005, 30) says blah. >>>> ^^^ According to Erik, this is just a possible output. It belongs to export configuration. >>>> 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]? All back-end may not be smart enough to compress years. However, it is probably equivalent for those that can. > Another issue is that it's not transpose-words safe. E.g. this output > seems bad: [-@k1 @k2 30] =3D> Y1 A2 (Y2, 30). This citation is invalid. The point of [@k1] is that the author is mandatory, since it is in-text, so [-@k1] doesn't make sense.=20 Also, it is not possible (as in Pandoc) to extract only year from a bibliography entry, so there's no way to have Y1 so far. > 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. Again, I was re-using examples. Let's forget about the "locator". > 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. They are not wrong. The output may decide to strip "p. ". This is not our problem at this stage of the discussion. >>> 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= =20 >>> 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. Org doesn't pretend to replace either LaTeX or biblatex. If extracting data from an entry is required, then I suggest to extend key syntax, e.g.: @K1:year But, again, if this is a LaTeX-only feature, org-ref and even raw LaTeX code is good enough. We shouldn't try to implement every possible feature, or we will fail. So, it is only an option if it can be implemented in most major export back-ends. > It's not unheard of. I have used it in the past. In LaTeX it's somethin= g like:=20 > > \citet[C]{k} =E2=86=92 A (Y, C) > \citet[B][]{k} =E2=86=92 A (B, Y) > \citet[B][C]{k} =E2=86=92 A (B, Y, C) I understand, but would it be needed to have both A (Y, C) and A (B, Y) in the same document? Otherwise, [@k text] can be treated either as A (text, Y) or A (Y, text) consistently throughout the document, according to bibliographic style. In any case, if we allow @key:tag syntax, then it is possible to do [@k:author] [cite: B -@k C] and get A (B, Y, C) > 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. [pre @k1 post] is slower to parse. (pre @k1 post) is worse because "(" is probably more common than "[". Really, round brackets should not be used for Org syntax. I haven't much against @k1, but it introduces more false positives than [@k1]. Regards,