From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: org-cite and org-citeproc Date: Thu, 02 Apr 2015 10:38:49 -0700 Message-ID: <87k2xue8gm.fsf@berkeley.edu> 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]:44538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydj5X-00016v-L8 for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 13:39:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ydj5U-0003qB-MC for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 13:39:31 -0400 Received: from plane.gmane.org ([80.91.229.3]:47756) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ydj5U-0003nQ-Bb for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 13:39:28 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ydj5S-0004jO-GZ for emacs-orgmode@gnu.org; Thu, 02 Apr 2015 19:39:26 +0200 Received: from c-67-169-117-151.hsd1.ca.comcast.net ([67.169.117.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Apr 2015 19:39:26 +0200 Received: from richard.lawrence by c-67-169-117-151.hsd1.ca.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Apr 2015 19:39:26 +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 Cc: Aaron Ecay Hi Aaron, Thanks for your comments, and for looking over my code! Aaron Ecay writes: > I’ve been (barely) following this discussion, but have been too busy to > do any actual coding. I sat down today to try to integrate Richard’s > branch with my work, but didn’t 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). In the long run, I agree, though I still think it might be good in the short term to see how a few different tools behave. > 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). (I take that as a compliment -- thanks! I'm curious as to what persuaded you.) > 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!). That is fine with me, as I think citeproc-js is the canonical implementation, and probably the best supported. I am not the person to do this, though, as I don't really know JavaScript, and personally I have found it rather frustrating to work with whenever I have had to do so. (I am a little puzzled, though, as to why you and Rasmus find the Haskell experience unpalatable. On my machine, I installed the Haskell Platform, and after that, building and installing pandoc, pandoc-citeproc, and other programs via cabal Just Works. Has that not been your experience? Why would instructions like "First install Node.js, then do: $ npm install org-citeproc" be better than "First install the Haskell platform, then do: $ cabal install org-citeproc"?) > 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. Yes, I agree, at least for those of us who don't use a citation manager. On the other hand, other people already have Zotero, but would find it difficult to install and configure a command-line tool and supporting platform. If there were a common API so that most of org-cite could operate independently of external tools, but call out to whichever tool was installed at critical moments, I think that would be beneficial from a user's perspective. (That was part of my motivation for representing citations to org-citeproc as citeproc-js-compatible JSON.) I know that would be more work, but it shouldn't lead to too much duplicated effort if we are careful to separate the tool-independent code from the tool-dependent code, and to minimize the latter. It would also make it easier to support new and better tools in the future as they become available. > 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’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). > > The second is whether the processor generates markup in the target > language directly (you) or whether the processor’s output is converted > to org markup, then passed through org’s 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.) Yes, I think that could work, and shouldn't be too hard to achieve, as Pandoc already has an Org writer. And I agree it is probably preferable to go this way. I realized this when I tested org-citeproc with a CSL file for a note-based style; things start to get complicated when you have to parse the output format to look for e.g. a footnote reference and definition. > 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. Ah, ok, I didn't know about json.el. Yes, I agree. > You wrote (mixing replies to various emails in this thread): > >> 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. > > 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. Hmm, OK, interesting. To me, this actually seems more complicated, but I guess I am probably not typical. As a fairly technical user I would personally prefer the flexibility of just writing a function that is responsible for taking a citation object and returning an arbitrary string to insert into the output. This seems simpler than worrying about which flavor of latex output I need, and therefore which type of customization is available. But I can see how things would be different for someone who doesn't want to learn enough Elisp to manipulate citation objects. >> Or maybe CITATION_STYLE should have "sub"-keywords, like >> >> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl > > This is equivalent (up to bikeshedding) to separate keywords. I’d 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). I agree. > 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. Alright, I'll try to move to json.el, and possibly change to having org-citeproc generate Org markup in the meantime. Best, Richard