Hi, Aaron Ecay <aarone...@gmail.com> 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