Re: org-cite and org-citeproc

[Rasmus <rasmus@gmx.us>]

Hi,

Aaron Ecay <aaronecay@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