From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Andr=C3=A1s?= Simonyi Subject: Re: Should wip-cite branch be merged to master? Date: Sun, 22 Apr 2018 20:17:47 +0200 Message-ID: <87in8jaywk.fsf@all.hu> References: <29b94436.a1e.162e54aa7c1.Coremail.tumashu@163.com> <871sf9f2ak.fsf@nicolasgoaziou.fr> 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]:57878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fAJYg-00044L-GW for emacs-orgmode@gnu.org; Sun, 22 Apr 2018 14:17:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fAJYd-000170-AW for emacs-orgmode@gnu.org; Sun, 22 Apr 2018 14:17:54 -0400 Received: from mail-wr0-x235.google.com ([2a00:1450:400c:c0c::235]:42812) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fAJYc-00015n-Vz for emacs-orgmode@gnu.org; Sun, 22 Apr 2018 14:17:51 -0400 Received: by mail-wr0-x235.google.com with SMTP id s18-v6so35215999wrg.9 for ; Sun, 22 Apr 2018 11:17:50 -0700 (PDT) In-reply-to: <871sf9f2ak.fsf@nicolasgoaziou.fr> 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" To: Nicolas Goaziou Cc: tumashu , emacs-orgmode , John Kitchin Dear All, thanks for bringing this up. I definitely agree that it'd be too early to m= erge the wip-cite branch. In fact, having added (experimental) support for it in citeproc-org I've been planning to propose some changes/extensions to the s= yntax but I wanted to wait until citeproc-org and citeproc-el become available as MELPA packages which still isn't the case (citeproc-el is already there but citeproc-org still needs some work before I can submit it). Anyhow, since t= he topic has come up, here is how I see the situation (sorry for the length): >From the citeproc-el/CSL point of view, the current syntax is perfect with = the notable exception of the provided citation commands. Currently only `cite' = and `(cite)' are supported, where the latter seems to be intended to provide the parenthetical version of a basic citation, e.g. in an author-date style `ci= te' would produce something like `Smith 2018` while `(cite)' `(Smith 2018)'. No= w I think that for author-date styles `cite' should produce the parenthetical version and that `(cite)' probably shouldn't be among the commands at all. = The main reason is that most citation processors (biblatex, CSL processors etc.) support not only author-date citation styles but footnote-based ones as wel= l, and the concept of a `parenthetical citation' doesn't really make sense for= the latter. A more abstract characterization which is applicable to all styles = is that normally references are not part of the main text, they are set off ei= ther by brackets or in a note. Since this is the most frequent, basic form, I th= ink this the one which should be produced by the `cite' syntax, that is, when u= sed in normal text `cite' should produce something like `(Smith 2018)' for author-date styles and a note with the reference for note styles. In addition to `cite', the following additional variants would be very useful, and would probably cover the majority of use-cases: - "bare cite": the same as cite, but doesn't separate the reference from the main text (no brackets/note); - "suppress author": removes the author's name from the citation. - "textual cite": includes the author's name in the main text but sets off the rest of the citation. A proposal for the syntax of the additional forms: bare cite could be indic= ated by a `-' suffix, suppress author by a `*' and textual cite by a `t' resulti= ng in the variants | command | result in author-date styles | |---------------+------------------------------| | cite | (Smith 2017) | | citet | Smith (2017) | | cite- | Smith 2017 | | cite* | (2017) | | cite*-/cite-* | 2017 | (omitting some combinatorial possibilities that don't make practical sense)= .=20 It would be a nice extra to also provide commands for adding an item to the= list of references without actually citing it (`nocite' command), and for adding literal cites (that provide the full text of the citation, and whose sole function is to let the processor know that a citation occurred at a certain location) but these are obviously not so important as the ones in the above table. The citeproc-el wiki contains a bit more information about this proposal: https://github.com/andras-simonyi/citeproc-el/wiki/Citation-types-and-comma= nds I'd be glad to hear your views regarding these issues. best regards, Andr=C3=A1s >> There is a package which support wip-cite: >> https://github.com/andras-simonyi/citeproc-org, should wip-cite >> branch be merged to master now? > Merging wip-cite branch with master, and integration of citeproc-org > into Org core, could be discussed with the author of the library, and, > of course, with anyone interested in using the @cite syntax. For > example, I need to know if that syntax, along with citeproc-org, covers > enough use-cases for citations, if it brings more value than using, > e.g., Org Ref, which already exists, how it could be improved, etc. > I have the feeling that it is a bit early for Org 9.2. Anyway, I'm > Cc'ing Andr=C3=A1s and John for their opinion about it. I'd love to hea= r from > everyone involved in the last round of discussion about the subject, > too. > Regards, > -- > Nicolas Goaziou