Hi Richard, hi all,
First of all, thanks very much for your work!
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).
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.
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.)
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 – 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.
> 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?
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.
I agree.
> 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).
> Can someone suggest how a parenthetical citation with common prefix and
> suffix data, like
>
> [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
> and references therein.]
>
> should map to plain BibTeX? Maybe there is no general answer to this
> question, but what would a reasonable default be? Maybe this?
>
> (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
> and references therein.)
>
> 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,
--
Aaron Ecay
