From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rasmus Subject: Re: org-cite and org-citeproc Date: Thu, 02 Apr 2015 21:17:34 +0200 Message-ID: <87mw2qtk4x.fsf@gmx.us> References: <87twx5hs2x.fsf@berkeley.edu> <87wq1u7clv.fsf@gmail.com> 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]:34806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydkci-0005nX-W4 for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 15:17:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ydkce-00081O-S9 for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 15:17:52 -0400 Received: from plane.gmane.org ([80.91.229.3]:54152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydkce-00081E-M8 for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 15:17:48 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ydkcc-0000Je-V1 for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 21:17:47 +0200 Received: from tsn109-201-154-158.dyn.nltelcom.net ([109.201.154.158]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Apr 2015 21:17:46 +0200 Received: from rasmus by tsn109-201-154-158.dyn.nltelcom.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Apr 2015 21:17:46 +0200 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, Aaron Ecay writes: > 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 – far > from non-technical people!). You mention zotero as a third option – > it’s possible, but I think we’d be better served by a tool that focuses > solely on processing and is not so closely tied with database > management. I mostly agree. IMO a non-binary Haskell solution is a non-starter for an "official" solution. A binary version is fine: e.g. I'm more or less happy with git-annex. I'd prefer java over node-js, but I'm less hostile towards npm. Could there be an elisp wrapper around citeproc-js? Likely, org devs would have an easier time maintaining such a beast. > The first is whether the processor generates the in-text citations (you) > or whether it’s done in elisp (me). It’s 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). IMO externalization is the top priority. After that I think elisp is superior as org-devs presumably would have an easier time maintaining this. >> This complicates things enough that probably custom citation modes >> [in Latex – AE] should be defined as Lisp functions, rather than via >> format strings...what do you think? > > I’d rather avoid it, since I think org->latex is going to be an important > 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. E.g. Natbib has primitives such as \citeauthor and \citeyear so arbitrarily complex biblatex citations can always be replicated. >> 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. +1 > 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. Richard: do your FSF papers in order. Or do you plan to get them in order? —Rasmus -- Send from my Emacs