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

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

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?  


> 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

> 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

  parent reply	other threads:[~2015-04-02 15:51 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 [this message]
2015-04-02 17:38   ` Richard Lawrence
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=87wq1u7clv.fsf@gmail.com \
    --to=aaronecay@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=richard.lawrence@berkeley.edu \


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