From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: Should wip-cite branch be merged to master? Date: Wed, 25 Apr 2018 12:19:47 -0700 Message-ID: <87efj39jqk.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> References: <29b94436.a1e.162e54aa7c1.Coremail.tumashu@163.com> <871sf9f2ak.fsf@nicolasgoaziou.fr> <87in8jaywk.fsf@all.hu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fBQf7-0004kq-C9 for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 16:05:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fBQf4-0003SM-5h for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 16:05:09 -0400 Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]:53565) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fBQf3-0003S3-RW for emacs-orgmode@gnu.org; Wed, 25 Apr 2018 16:05:06 -0400 Received: by mail-wm0-x236.google.com with SMTP id 66so9140938wmd.3 for ; Wed, 25 Apr 2018 13:05:05 -0700 (PDT) In-Reply-To: <87in8jaywk.fsf@all.hu> 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: =?utf-8?Q?Andr=C3=A1s?= Simonyi , Nicolas Goaziou Cc: tumashu , emacs-orgmode , John Kitchin --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi everyone, I don't have too much to add to this, though I do want to thank=20 everyone for their continued interest in citations, and the work=20 that has been done! Since the question of syntax has come up again, I guess I want to=20 address one point that Andr=C3=A1s made: =20 Andr=C3=A1s Simonyi writes: > From the citeproc-el/CSL point of view, the current syntax is=20 > perfect with the notable exception of the provided citation=20 > commands. Currently only `cite' and `(cite)' are supported,=20 > where the latter seems to be intended to provide the=20 > parenthetical version of a basic citation, e.g. in an=20 > author-date style `cite' would produce something like `Smith=20 > 2018` while `(cite)' `(Smith 2018)'. Now I think that for=20 > author-date styles `cite' should produce the parenthetical=20 > version and that `(cite)' probably shouldn't be among the=20 > commands at all. The main reason is that most citation=20 > processors (biblatex, CSL processors etc.) support not only=20 > author-date citation styles but footnote-based ones as well, and=20 > the concept of a `parenthetical citation' doesn't really make=20 > sense for the latter.=20 I think this actually gets at one of the fundamental problems with=20 citations, namely, they resist attempts to separate 'content' from=20 'style'. It is hard to insert citations into a document without=20 making any assumptions about how they will be rendered by the=20 citation processor. And so it is hard to come up with a syntax=20 that is general enough to represent widely different citation=20 styles, in a way that makes those assumptions explicit in the=20 syntax of the unprocessed citation, so that the content of the=20 citation can be separated from how it will be rendered. Thus we=20 see the huge proliferation of different citation commands in=20 e.g. BibLaTeX, natbib, and similar packages. Andr=C3=A1s' proposal=20 would reintroduce some of the complexity of BibLaTeX citation=20 commands at the level of Org syntax. Maybe having multiple citation commands is ultimately the best way=20 to go, but I want to point out that one of the goals of the=20 original discussion to come up with an Org syntax that is simpler=20 and does a better job of separating content and style. Anyway,=20 that was one of my goals in synthesizing people's various=20 suggestions and needs into a concrete syntax proposal. I think we=20 should try to avoid proliferation of citation commands. If that is a reasonable goal, then I think there is really just=20 one distinction that deserves to be represented at the level of=20 citation commands: the distinction between 'in text' and=20 'parenthetical' citations, that is, the distinction between=20 'cite:' and '(cite):' in the current syntax in wip-cite. That=20 brings me to this point: > A more abstract characterization which is applicable to all=20 > styles is that normally references are not part of the main=20 > text, they are set off either by brackets or in a note. Since=20 > this is the most frequent, basic form, I think this the one=20 > which should be produced by the `cite' syntax, that is, when=20 > used in normal text `cite' should produce something like `(Smith=20 > 2018)' for author-date styles and a note with the reference for=20 > note styles. I think Andr=C3=A1s' abstract characterization is exactly right: the=20 issue here is not really about whether the citation has brackets=20 around it. Instead, it is about whether the rendered citation is=20 intended to be *read as part of the surrounding sentence*=20 ('in-text'), or whether it is *grammatically independent* of the=20 main text ('parenthetical'). I disagree, however, that=20 'parenthetical' citations are the normal or usual case; I think=20 that depends completely on one's field, writing style, etc. (In=20 my dissertation, for example, in-text citations outnumber=20 parenthetical citations roughly 3:2.)=20 The 'in-text' vs. 'parenthetical'/'out-of-text' distinction is=20 really the fundamental one that you can't abstract from as an=20 author. And it seems to me that apart from this decision, most of=20 the other decisions about styling can handed off to the citation=20 processor, via a choice of CSL file, at least for the out-of-text=20 case: is it a note-based style, or a Harvard-like one? etc. The in-text case is a little trickier because you need a way to=20 represent the different kinds of data that might be intended to=20 fit into the surrounding sentence (author name? year? both? just a=20 number? etc.). But there are many many possibilities here, and=20 for that reason I think it is better to avoid making them=20 primitive citation commands. Instead we should just stick to one=20 command for the in-text case, and have some extensible way to=20 represent the data that should be rendered, e.g. maybe like [cite: @Jones2018 :year] or (as I think was proposed at one point): [cite:author @Jones2018] Again, maybe it's worth having some shortcuts here for the common=20 cases, but I think in general we want to try to avoid=20 proliferation of basic citation commands. So for that reason I=20 think we should just stick with the 'cite'/'(cite)' distinction as=20 the two basic commands, perhaps with a more=20 extensible/compositional syntax in each case for expressing the=20 variations on these two basic types of citation. =2D-=20 Best, Richard --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEgGDlsvLEBgbmTW4HmWlD4c9vpkYFAlrg1NMACgkQmWlD4c9v pkbdiwf/U1YNCb3Eo+Kw5LSBR0LobHiS8W7yL9wo9vQQwWxkodniEXTVzaExhjy/ U+ISLZdffZ+2AiZD/hBRMlqTNYCZxjlv/PYA2IVu3f9fOXyisHuRdC/XI2A8pQaG KcU4pSco6TTA1LyoFrxTsUQt9SBbYQ0g4tC+J5AN5qvDv1VEbRaboqnfoUdqTvye vwP9ZSAYk4epXpwY3P/9Z/K+mBxZyJvTYKqtPAgYEgWixCA0bgnBDU23fZeqvBmO a5k6nEbUdzraI02wQHXI5TxhLto+0x11FQBDQVhB8Yp8w9FL+mHVWgvbnTSj1BOt k93LBUWhsbzSvsvzHKev8N6bavccZw== =/VQD -----END PGP SIGNATURE----- --=-=-=--