emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: emacs-orgmode@gnu.org
Cc: Aaron Ecay <aaronecay@gmail.com>
Subject: Re: org-cite and org-citeproc
Date: Thu, 02 Apr 2015 10:38:49 -0700	[thread overview]
Message-ID: <87k2xue8gm.fsf@berkeley.edu> (raw)
In-Reply-To: <87wq1u7clv.fsf@gmail.com>

Hi Aaron,

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

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

> 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

(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

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

> 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.


  reply	other threads:[~2015-04-02 17:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-28 18:53 Richard Lawrence
2015-03-31  8:16 ` Eric S Fraga
2015-03-31 19:13   ` Richard Lawrence
2015-03-31 19:34     ` Nick Dokos
2015-03-31 20:29       ` Thomas S. Dye
2015-03-31 21:57         ` Richard Lawrence
2015-04-01  0:41           ` Thomas S. Dye
2015-04-01 15:42             ` Richard Lawrence
2015-04-01 19:41               ` Thomas S. Dye
2015-04-02 15:57                 ` Richard Lawrence
2015-04-02 16:45                   ` Thomas S. Dye
2015-03-31 21:12     ` Eric S Fraga
2015-04-01  7:49       ` Andreas Leha
2015-04-02 14:29         ` Eric S Fraga
2015-04-02 15:11           ` Richard Lawrence
2015-04-02 19:26             ` Andreas Leha
2015-03-31 22:03     ` Rasmus
2015-04-01 14:39       ` Richard Lawrence
2015-04-02  0:08         ` Rasmus
2015-04-02 15:26           ` Richard Lawrence
2015-04-02 15:51 ` Aaron Ecay
2015-04-02 17:38   ` Richard Lawrence [this message]
2015-04-06 18:51     ` Richard Lawrence
2015-06-16 19:36       ` Matt Price
2015-06-18 22:44         ` Richard Lawrence
2015-04-02 19:17   ` Rasmus
2015-04-03  2:56     ` Richard Lawrence

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k2xue8gm.fsf@berkeley.edu \
    --to=richard.lawrence@berkeley.edu \
    --cc=aaronecay@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).