From: Richard Lawrence <email@example.com>
Cc: Aaron Ecay <firstname.lastname@example.org>
Subject: Re: org-cite and org-citeproc
Date: Thu, 02 Apr 2015 10:38:49 -0700 [thread overview]
Message-ID: <email@example.com> (raw)
Thanks for your comments, and for looking over my code!
Aaron Ecay <firstname.lastname@example.org> 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
(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
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
> 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
>> 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 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.
next prev parent 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
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 \
* 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).