emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] org-cite and org-citeproc


From: Richard Lawrence
Subject: Re: [O] org-cite and org-citeproc
Date: Thu, 02 Apr 2015 10:38:49 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Hi Aaron,

Thanks for your comments, and for looking over my code!

Aaron Ecay <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]