From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: org-cite and org-citeproc Date: Thu, 02 Apr 2015 16:51:08 +0100 Message-ID: <87wq1u7clv.fsf@gmail.com> References: <87twx5hs2x.fsf@berkeley.edu> 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]:43908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdhOl-0001fU-R5 for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 11:51:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdhOi-0001Pk-HH for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 11:51:15 -0400 Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:35789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdhOi-0001Pc-6a for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 11:51:12 -0400 Received: by widdi4 with SMTP id di4so83350682wid.0 for ; Thu, 02 Apr 2015 08:51:11 -0700 (PDT) In-Reply-To: <87twx5hs2x.fsf@berkeley.edu> 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: Richard Lawrence , emacs-orgmode@gnu.org Hi Richard, hi all, First of all, thanks very much for your work! I=E2=80=99ve been (barely) following this discussion, but have been too bus= y to do any actual coding. I sat down today to try to integrate Richard=E2=80= =99s branch with my work, but didn=E2=80=99t get very far. I think it would be a waste of effort to try to support more than one citation processor (citeproc-java vs. org-citeproc). I went round and round with myself about this, and concluded that we ought to keep on working on the org-citeproc approach for now (drop citeproc-java). But I do think someone eventually ought to reimplement org-citeproc based on citeproc-js, to yield something that can be distributed via npm. This will be less fool-proof than java, but better than the Haskell experience for many users (such as Rasmus and me =E2=80=93= far from non-technical people!). You mention zotero as a third option =E2=80=93 it=E2=80=99s possible, but I think we=E2=80=99d be better served by a tool = that focuses solely on processing and is not so closely tied with database management. There are a couple of other differences in our approaches. The first is whether the processor generates the in-text citations (you) or whether it=E2=80=99s done in elisp (me). It=E2=80=99s not obvious which= is superior. The real test will come when more diverse citation types are implemented (e.g. full citations in footnotes or numbers which reference a numbered bibliography at the end of the document). The second is whether the processor generates markup in the target language directly (you) or whether the processor=E2=80=99s output is conver= ted to org markup, then passed through org=E2=80=99s exporters (me). I think my approach here is preferable, since it generalizes to every backend. Do you think something like this could work for org-citeproc? It would probably require some additional special code in ox-odt. (But we might need that in any case, see below.) It would be good from an intelligibility/maintainability perspective if you could use the json.el library rather than generating json strings by hand. This is part of the emacs core since version 23.something, so compatibility should not be a big issue. You wrote (mixing replies to various emails in this thread): > This complicates things enough that probably custom citation modes > [in Latex =E2=80=93 AE] should be defined as Lisp functions, rather than = via > format strings...what do you think? I=E2=80=99d rather avoid it, since I think org->latex is going to be an imp= ortant usecase for many people. I see us eventually supporting two flavors of latex output. The first should aim to generate a full set of biblatex commands but with little user customizability. The second will rely on just 2 citation commands (paren and non-paren), plus some elisp routines for combining them into multicites etc. These two cite commands then can be customized by the user. If people need more flexibility but cannot use biblatex, they can always hack up a custom exporter for themselves. But I think we ought to support relatively simple needs with simple configuration settings. > OK, I see, that makes things clearer. Would it make sense to have two > keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the > style can vary independently when exporting to LaTeX vs. non-LaTeX?=20=20 Yes. > I'm thinking it will be tricky to come up with a single set of values > for a CITATION_STYLE keyword that can be correctly mapped to both > kinds of backend.=20=20 I agree. > Or maybe CITATION_STYLE should have "sub"-keywords, like >=20 > #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl This is equivalent (up to bikeshedding) to separate keywords. I=E2=80=99d = like the bikeshed painted with separate keywords, though, because that leaves room for passing additional options to biblatex (to be added to the \usepackage and/or \printbibliography commands). > Can someone suggest how a parenthetical citation with common prefix and > suffix data, like >=20 > [(cite): For more on this topic, see:; @Work1 for a review; @Work2; > and references therein.]=20 >=20 > should map to plain BibTeX? Maybe there is no general answer to this > question, but what would a reasonable default be? Maybe this? >=20 > (For more on this topic, see: \cite{Work1} for a review, \cite{Work2}, > and references therein.) >=20 > That is, just place the prefix and suffix data in the surrounding text, > inserting commas after the part for each individual work, and wrapping > the whole thing in parentheses? I agree. (This is like the second flavor of latex support I described above.) > Also useful. This might take a while for me to figure out, as Pandoc > does not seem to generate this markup when formatting a > bibliography...maybe I'll see if they are willing to work on this > upstream. I think we should not rely on pandoc to fix this for us. It makes it harder to move away from Haskell if (when) we want to. I used up all the time I had today to understanding the code and surrounding conceptual issues. However, I will try to integrate your changes with my branch sometime in the next few days-week. Thanks again, --=20 Aaron Ecay