Re: [O] org-cite and org-citeproc
Hi Matt, Matt Price mopto...@gmail.com writes: I'm wondering what kind of work is required to make use of org-cite and org-citeproc at present. In particular, I'm wondering what kinds of changes I'll need to make to my current setup, and whether it's worthwhile to use my ultra-slow coding skills to create whatever glue is still necessary. At the moment, org-cite/org-citeproc has no way of talking to Zotero. So you'd need to manually export citation data from Zotero to a format that pandoc-citeproc understands, like BibTex. It sounds like zotxt and zotxt-emacs provide a lot of what's needed to glue org-cite together with Zotero; so one thing that would be helpful, if you're up for it, is hacking org-cite to pull bibliography data from Zotero in a format that can be passed to org-citeproc. I don't use Zotero myself, so this is something I'm unlikely to do anytime soon without some help. (Borrowing code from zotxt-emacs and putting it in org-cite is probably the way to go here, as I doubt that we want to make zotxt-emacs a dependency of org-cite.) All of this is fine for my current purposes, but I would like to figure out a more flexible and enduring solution, so I'd like to try out org-cite and org-citeproc. But I'm not quite sure what's required, and whether there's support currently for odt and html export. `Flexible and enduring' does not describe org-citeproc at the moment. :) I'd be very happy to have you test out org-citeproc and give feedback that will help improve it, but I can't recommend that you rely on it or switch to it for serious work any time soon. It is a working proof-of-concept, but only that. Still, there is support in org-cite/org-citeproc for both HTML and ODT export, and it handles quite a few of the common cases. So let me know if you're interested in trying it out. There are brief installation instructions in the README (https://github.com/wyleyr/org-citeproc); let me know if you need more than that. Best, Richard
Re: [O] org-cite and org-citeproc
On Mon, Apr 6, 2015 at 2:51 PM, Richard Lawrence
richard.lawre...@berkeley.edu wrote:
Hi Aaron and all,
Richard Lawrence richard.lawre...@berkeley.edu writes:
Alright, I'll try to move to json.el, and possibly change to having
org-citeproc generate Org markup in the meantime.
Just a heads up: I've pushed some changes to my branch of Org to make
org-cite use json.el, and to add a basic Org format writer to
org-citeproc.
I have not made any other changes to org-cite to use the Org formatted
output from org-citeproc, though, as I believe doing this properly will
involve parsing the output and inserting it into Org's exporter's parse
tree (to accommodate the bibliography and note-based styles). I won't
have time to work on that this week, but I'll come back to it.
Best,
Richard
Hi Richard et al,
I'm wondering what kind of work is required to make use of org-cite and
org-citeproc at present. In particular, I'm wondering what kinds of changes
I'll need to make to my current setup, and whether it's worthwhile to use
my ultra-slow coding skills to create whatever glue is still necessary.
Here's my setup at present:
I currently use Zotero for most of my bibliography management; it's
relatively easy to get zotero to export a bibtex bibliography (cf.
https://github.com/robintw/AutoZotBib), and I will switch to bibtex if
absolutely necessary. I'd rather just keep using Zotero, though.
I use zotxt-emacs to insert references in org files.
I export my work to html and odt. I use this small bit of code to manage
exports:
;; zotxt
(org-add-link-type zotero
(lambda (rest)
(zotxt-select-key (substring rest 15)))
(lambda (path desc format)
(if (string-match ^@\\(.*\\)$ desc)
(cond ((eq format 'latex)
(format \\cite{%s} (match-string 1 desc)))
((eq format 'md)
desc)
((eq format 'html)
(deferred:$
(zotxt-get-item-bibliography-deferred
`(:key , (substring path 15)))
(deferred:nextc it
(lambda (item)
(plist-get item :citation-html)))
(deferred:sync! it)))
((eq format 'odt)
(deferred:$
(zotxt-get-item-deferred `(:key ,
(substring path 15)) :248bebf1-46ab-4067-9f93-ec3d2960d0cd)
(deferred:nextc it
(lambda (item)
(plist-get item
:248bebf1-46ab-4067-9f93-ec3d2960d0cd)))
(deferred:sync! it)))
(t nil)
nil
currently this grabs a full html citation and pastes it into the html
export, while for odt it produces strings of the form { | Herzig, 2006 | |
|zotero://select/items/0_SKDIF737}, which Zotero can understand withthe aid
of an RDF/ODF scan plugin.
All of this is fine for my current purposes, but I would like to figure out
a more flexible and enduring solution, so I'd like to try out org-cite and
org-citeproc. But I'm not quite sure what's required, and whether there's
support currently for odt and html export.
Thanks very much for your help,
Matt
Re: [O] org-cite and org-citeproc
Hi Aaron and all, Richard Lawrence richard.lawre...@berkeley.edu writes: Alright, I'll try to move to json.el, and possibly change to having org-citeproc generate Org markup in the meantime. Just a heads up: I've pushed some changes to my branch of Org to make org-cite use json.el, and to add a basic Org format writer to org-citeproc. I have not made any other changes to org-cite to use the Org formatted output from org-citeproc, though, as I believe doing this properly will involve parsing the output and inserting it into Org's exporter's parse tree (to accommodate the bibliography and note-based styles). I won't have time to work on that this week, but I'll come back to it. Best, Richard
Re: [O] org-cite and org-citeproc
Hi,
Richard Lawrence richard.lawre...@berkeley.edu writes:
Hi Eric and all,
Eric S Fraga e.fr...@ucl.ac.uk writes:
On Wednesday, 1 Apr 2015 at 08:49, Andreas Leha wrote:
[...]
I am a happy biblatex user for all my 'own' documents. But (as was
mentioned previously) scientific journals that accept latex submissions
will require bibtex and won't support biblatex. So, I'd say that one of
the other methods (preferably bibtex) is still necessary.
Ahhh, yes, I'd forgotten that journals expect bibtex. This is a key
requirement for me as well therefore.
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?
To me that seems a reasonable thing to do. At least I would write it
probably in such a way.
Depending on the citation style (author, year) I might add a comma
after the citation, so that it becomes
(For more on this topic, see: Max Mustermann, 2015, for a review,
The Internet Consortium, 2014, and references therein.)
compared to
(For more on this topic, see: Max Mustermann, 2015 for a review,
The Internet Consortium, 2014 and references therein.)
But:
- I am no native English speaker and comma placement in English
is very unclear to me
- my citation requirements are quite low, I guess...
Best,
Andreas
Re: [O] org-cite and org-citeproc
Rasmus ras...@gmx.us writes: Richard: do your FSF papers in order. Or do you plan to get them in order? I haven't done them yet (never had a reason to!) but I have no problems with it and I'll get started on it. Best, Richard
Re: [O] org-cite and org-citeproc
Hi, Aaron Ecay aarone...@gmail.com writes: 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. I mostly agree. IMO a non-binary Haskell solution is a non-starter for an official solution. A binary version is fine: e.g. I'm more or less happy with git-annex. I'd prefer java over node-js, but I'm less hostile towards npm. Could there be an elisp wrapper around citeproc-js? Likely, org devs would have an easier time maintaining such a beast. 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). IMO externalization is the top priority. After that I think elisp is superior as org-devs presumably would have an easier time maintaining this. 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. E.g. Natbib has primitives such as \citeauthor and \citeyear so arbitrarily complex biblatex citations can always be replicated. 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. +1 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. Richard: do your FSF papers in order. Or do you plan to get them in order? —Rasmus -- Send from my Emacs
Re: [O] org-cite and org-citeproc
Hi Tom and all, t...@tsdye.com (Thomas S. Dye) writes: 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. Or maybe CITATION_STYLE should have sub-keywords, like #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl Won't the backends sort this out without the additional mapping? Surely they could, but I guess I'm unclear on how that should happen. Org could keep a variable mapping citation styles to default values for the respective backends, like: (defcustom org-cite-citation-styles '((author-year (biblatex-pkg-args citestyle=authoryear,bibstyle=authoryear) (csl-file /path/to/chicago-author-date.csl)) ...)) so in a document, you could just write #+CITATION_STYLE: author-year or similar. Is this what you have in mind? That seems like a good way to provide reasonable defaults using a high-level label. But I think using a high-level label like this will underdetermine the actual style to use (on both sides, I assume); and the problem is that if we make the labels more fine-grained, there's no longer any guarantee that, for a given style label, a suitable style file will be available on both LaTeX and non-LaTeX backends. There obviously needs to be some mechanism so authors can specify their citation style quite precisely for the backends they are interested in. (Maybe just customizing this variable would do the trick.) But what should the fallback mechanism look like when a particular style does not specify the required information for a given export backend? E.g., if CITATION_STYLE is X and we're exporting to HTML, but the entry in org-cite-citation-styles does not specify a CSL file for style X? Would it be enough to have a single 'default clause or similar in org-cite-citation-styles to use in that kind of case? Best, Richard
Re: [O] org-cite and org-citeproc
Hi Rasmus, Thanks, this is helpful. I will try to fix these things soon. Rasmus ras...@gmx.us writes: Hmm. But the citations are all just represented as text:p nodes...surely that doesn't have to be defined elsewhere? You are right. Also, oolatex inserts citations as plain text as well. As I recall, it can be done semantically and section 6.3 of the odt standard suggest that this may be true, but it's not immediately obvious how to do it. I am now guessing that the problem is that you can't have one text:p inside another. Each paragraph is wrapped in a text:p, but so are the citations within it...maybe that is not correct and so LibreOffice doesn't like it. I don't think text:p can be nested cf. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415138_253892949 OK, good to know. Looks like text:reference-mark or text:note might be the way to go. Also, the bibliography is not correct in the sense that if it was setup in the right semantic way, it would be gray in LO, like the TOC. Do you know what other markup is required in this case? It looks like maybe the TOC is gray because it is marked with a text:protected attribute, or maybe because it has an associated OrgIndexSection style? It has to be formatted as a bibliography. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_bibliography 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. Best, Richard
Re: [O] org-cite and org-citeproc
Hi Eric and all,
Eric S Fraga e.fr...@ucl.ac.uk writes:
On Wednesday, 1 Apr 2015 at 08:49, Andreas Leha wrote:
[...]
I am a happy biblatex user for all my 'own' documents. But (as was
mentioned previously) scientific journals that accept latex submissions
will require bibtex and won't support biblatex. So, I'd say that one of
the other methods (preferably bibtex) is still necessary.
Ahhh, yes, I'd forgotten that journals expect bibtex. This is a key
requirement for me as well therefore.
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?
Thanks!
Best,
Richard
Re: [O] org-cite and org-citeproc
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
Re: [O] org-cite and org-citeproc
On Wednesday, 1 Apr 2015 at 08:49, Andreas Leha wrote: [...] I am a happy biblatex user for all my 'own' documents. But (as was mentioned previously) scientific journals that accept latex submissions will require bibtex and won't support biblatex. So, I'd say that one of the other methods (preferably bibtex) is still necessary. Ahhh, yes, I'd forgotten that journals expect bibtex. This is a key requirement for me as well therefore. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84
Re: [O] org-cite and org-citeproc
Hi Richard, Richard Lawrence richard.lawre...@berkeley.edu writes: Hi Tom and all, t...@tsdye.com (Thomas S. Dye) writes: 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. Or maybe CITATION_STYLE should have sub-keywords, like #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl Won't the backends sort this out without the additional mapping? Surely they could, but I guess I'm unclear on how that should happen. Org could keep a variable mapping citation styles to default values for the respective backends, like: (defcustom org-cite-citation-styles '((author-year (biblatex-pkg-args citestyle=authoryear,bibstyle=authoryear) (csl-file /path/to/chicago-author-date.csl)) ...)) so in a document, you could just write #+CITATION_STYLE: author-year or similar. Is this what you have in mind? That seems like a good way to provide reasonable defaults using a high-level label. But I think using a high-level label like this will underdetermine the actual style to use (on both sides, I assume); and the problem is that if we make the labels more fine-grained, there's no longer any guarantee that, for a given style label, a suitable style file will be available on both LaTeX and non-LaTeX backends. There obviously needs to be some mechanism so authors can specify their citation style quite precisely for the backends they are interested in. (Maybe just customizing this variable would do the trick.) But what should the fallback mechanism look like when a particular style does not specify the required information for a given export backend? E.g., if CITATION_STYLE is X and we're exporting to HTML, but the entry in org-cite-citation-styles does not specify a CSL file for style X? Would it be enough to have a single 'default clause or similar in org-cite-citation-styles to use in that kind of case? I was thinking the author would change CITATION_STYLE to fit the export, but I like your idea of setting up a universal configuration. As for a fallback mechanism, I like your idea of a user-configurable default. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-cite and org-citeproc
Hi Aaron, Thanks for your comments, and for looking over my code! Aaron Ecay aarone...@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 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
Re: [O] org-cite and org-citeproc
Hi, Eric S Fraga e.fr...@ucl.ac.uk writes: On Tuesday, 31 Mar 2015 at 12:13, Richard Lawrence wrote: Hi Eric and all, Eric S Fraga e.fr...@ucl.ac.uk writes: [...] However, for some reason, libreoffice doesn't display the citations in the ODT document you have included. I have had a look at the actual ODT file and it looks fine. Can you suggest what may be wrong? Hmm, you're right. I don't have LibreOffice on the machine where I am working on org-citeproc, but I tested it on another machine (OS X, LibreOffice version 4.2.8.2 I think), and the citation text is indeed missing. Thanks for confirming this. At least it's not me! I hope somebody can figure out what is going on here. [...] A second question: what will be required to use the new cite syntax with LaTeX/PDF which will remain my main target for export? I think this needs more discussion, actually. The citation syntax can basically be mapped directly to BibLaTeX syntax, so generating LaTeX that will be processed with BibLaTeX is a simple and straightforward modification to Org's LaTeX exporter, and compiling the Although I normally use bibtex, I am happy moving to biblatex if it means unifying org's citation approaches. I don't need the extra features (e.g. multicite) in practice but I'm also not attached to bibtex. I am a happy biblatex user for all my 'own' documents. But (as was mentioned previously) scientific journals that accept latex submissions will require bibtex and won't support biblatex. So, I'd say that one of the other methods (preferably bibtex) is still necessary. Regards, Andreas
Re: [O] org-cite and org-citeproc
Rasmus ras...@gmx.us writes: Richard Lawrence richard.lawre...@berkeley.edu writes: I don't really know anything about the ODT format, though. My code more-or-less blindly pastes Pandoc-generated XML into the document during Org ODT export. Can someone who knows more about the format take a look at the file and see if there is some subtle problem I'm not noticing? I can't test your code 'cause I, for personal/silly reasons, refuse to spend any more dealing with compiling Haskell. Fair enough. :) That being said, my gut feeling is that you have to define the data elsewhere. For example, to add a (sub)title to a odt document the field/keyword is defined in a file different from contents.xml and will just not be printed if used in contents.xml only. Hmm. But the citations are all just represented as text:p nodes...surely that doesn't have to be defined elsewhere? I am now guessing that the problem is that you can't have one text:p inside another. Each paragraph is wrapped in a text:p, but so are the citations within it...maybe that is not correct and so LibreOffice doesn't like it. Also, the bibliography is not correct in the sense that if it was setup in the right semantic way, it would be gray in LO, like the TOC. Do you know what other markup is required in this case? It looks like maybe the TOC is gray because it is marked with a text:protected attribute, or maybe because it has an associated OrgIndexSection style? Thanks! Best, Richard
Re: [O] org-cite and org-citeproc
Hi Tom and all, Thanks for answering my questions! t...@tsdye.com (Thomas S. Dye) writes: With natbib, it is possible to give a pre-note and a post-note to the citation as a whole, but not to individual citations within it. In order to support your syntax fully, I think BibLaTeX is needed. OK, good to know. (Also, do you think it is important to support plain BibTeX at all? It seems like we should not bother with this problem unless it's important for a lot of people. I personally would be fine with just targeting BibLaTeX, and it sounds like Eric would be too.) Well, one benefit of Aaron's function was to make this choice superfluous, both now and in the future. It binds the two citation commands you've implemented to citation commands implemented in CITATION_STYLE. As Aaron notes, it should be easy to modify this (to bind additional commands) when advanced citation support comes along. I think I have to retract what I said earlier: I doubt this part of Aaron's code still works in my branch, because I think Aaron was assuming citation objects contain just one reference; in my branch, I've merged in the parser support Nicolas later implemented for multi-cite citations. So a CITATION_MODE needs to know how to turn a list of works, each with associated prefix and suffix data, into a complete citation command. This complicates things enough that probably custom citation modes should be defined as Lisp functions, rather than via format strings...what do you think? I'm still having a hard time seeing what an analogous customization would look like for non-LaTeX backends. The LaTeX exporter is unique in that Org produces output which must then be further processed by another tool, so having customizable control over how a citation `looks' to that tool makes sense. But in other backends, the Org exporter itself produces the final document; there's no intermediate representation besides Org's own, plus whatever arguments are passed to a citation processing tool like org-citeproc. So, if that's right, the analogous customization in a non-LaTeX backend would be something like a filter, one that pre-processes citation objects before they are run through the external tool, or that post-processes the strings that come back (or both). Does that make sense? Certainly, both of those things are possible. Typically, a bibliography style file defines several citation commands, which might belong to one or more modes. ... I think you might be able to merge CSL_FILE and CITATION_STYLE, since they both point to a style file. 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. Or maybe CITATION_STYLE should have sub-keywords, like #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl or something similar? Best, Richard
Re: [O] org-cite and org-citeproc
Hi,
Richard Lawrence richard.lawre...@berkeley.edu writes:
That being said, my gut feeling is that you have to define the data
elsewhere.
For example, to add a (sub)title to a odt document the field/keyword is
defined in a file different from contents.xml and will just not be printed
if used in contents.xml only.
Hmm. But the citations are all just represented as text:p
nodes...surely that doesn't have to be defined elsewhere?
You are right. Also, oolatex inserts citations as plain text as well. As
I recall, it can be done semantically and section 6.3 of the odt
standard suggest that this may be true, but it's not immediately obvious
how to do it.
I am now guessing that the problem is that you can't have one text:p
inside another. Each paragraph is wrapped in a text:p, but so are the
citations within it...maybe that is not correct and so LibreOffice
doesn't like it.
I don't think text:p can be nested cf.
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415138_253892949
Also, the bibliography is not correct in the sense that if it was setup
in the right semantic way, it would be gray in LO, like the TOC.
Do you know what other markup is required in this case? It looks like
maybe the TOC is gray because it is marked with a text:protected
attribute, or maybe because it has an associated OrgIndexSection
style?
It has to be formatted as a bibliography.
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_bibliography
I've attached a minimal oolatex example (mk4ht oolatex test.tex) of
\documentclass{article}
\usepackage[english]{babel}
\usepackage[authordate]{biblatex-chicago}
\addbibresource{~/documents/literature/lit.bib}
\begin{document}
before \textcite[pre][post]{schulte12} and after
\printbibliography
\end{document}
Hope it helps,
Rasmus
--
. . . The proofs are technical in nature and provides no real understanding
test.odt
Description: application/vnd.oasis.opendocument.text
Re: [O] org-cite and org-citeproc
Aloha Richard,
Richard Lawrence richard.lawre...@berkeley.edu writes:
Hi Tom and all,
Thanks for answering my questions!
t...@tsdye.com (Thomas S. Dye) writes:
With natbib, it is possible to give a pre-note and a post-note to the
citation as a whole, but not to individual citations within it. In
order to support your syntax fully, I think BibLaTeX is needed.
OK, good to know.
(Also, do you think it is important to support plain BibTeX at all? It
seems like we should not bother with this problem unless it's important
for a lot of people. I personally would be fine with just targeting
BibLaTeX, and it sounds like Eric would be too.)
Well, one benefit of Aaron's function was to make this choice
superfluous, both now and in the future. It binds the two citation
commands you've implemented to citation commands implemented in
CITATION_STYLE. As Aaron notes, it should be easy to modify this (to
bind additional commands) when advanced citation support comes along.
I think I have to retract what I said earlier: I doubt this part of
Aaron's code still works in my branch, because I think Aaron was
assuming citation objects contain just one reference; in my branch, I've
merged in the parser support Nicolas later implemented for multi-cite
citations. So a CITATION_MODE needs to know how to turn a list of
works, each with associated prefix and suffix data, into a complete
citation command.
This complicates things enough that probably custom citation modes
should be defined as Lisp functions, rather than via format
strings...what do you think?
I'm still having a hard time seeing what an analogous customization
would look like for non-LaTeX backends. The LaTeX exporter is unique in
that Org produces output which must then be further processed by another
tool, so having customizable control over how a citation `looks' to that
tool makes sense. But in other backends, the Org exporter itself
produces the final document; there's no intermediate representation
besides Org's own, plus whatever arguments are passed to a citation
processing tool like org-citeproc. So, if that's right, the analogous
customization in a non-LaTeX backend would be something like a filter,
one that pre-processes citation objects before they are run through the
external tool, or that post-processes the strings that come back (or
both). Does that make sense? Certainly, both of those things are
possible.
Yes, I think an export filter would work for LaTeX.
The general form for BibLaTeX is:
\cites(⟨multiprenote⟩)(⟨multipostnote⟩)[⟨prenote⟩][⟨postnote⟩]{⟨key⟩}...[⟨prenote⟩][⟨postnote⟩]{⟨key⟩}
where \cites can also be \parencites, \textcites, etc.
For natbib it is:
\cite[⟨prenote⟩][⟨postnote⟩]{⟨key⟩,...⟨key⟩}
where \cite can also be \citep, \citet, etc.
Typically, a bibliography style file defines several citation commands,
which might belong to one or more modes. ...
I think you might be able to merge CSL_FILE and CITATION_STYLE, since
they both point to a style file.
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. Or maybe CITATION_STYLE should have sub-keywords, like
#+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl
Won't the backends sort this out without the additional mapping?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] org-cite and org-citeproc
On Saturday, 28 Mar 2015 at 10:53, Richard Lawrence wrote: Hi everyone, I thought I should send an update to let you know that org-citeproc [1], the command-line citation processing tool I've been working on, now supports multi-cites. I believe that means it is now capable of processing all citations in the basic citation syntax. It can output plain text, HTML, and ODT (and a Pandoc native format, mostly useful for debugging). This looks really good! Thanks. However, for some reason, libreoffice doesn't display the citations in the ODT document you have included. I have had a look at the actual ODT file and it looks fine. Can you suggest what may be wrong? I'm attaching a crop of a screenshot to illustrate what I mean. Highlighted is where I would have expected to see some text for the citation. A second question: what will be required to use the new cite syntax with LaTeX/PDF which will remain my main target for export? Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-820-gd92ef9
Re: [O] org-cite and org-citeproc
Richard Lawrence richard.lawre...@berkeley.edu writes: However, there are a couple of other scenarios to think about: 1) Some people may still need to use plain BibTeX. Generating LaTeX that is intended to be processed with BibTeX, as opposed to BibLaTeX, is a little trickier, because (IIUC) BibTeX does not support multi-cite citations. I know next to nothing about citations in general, so please bear with me: if multi-cite support means being able to condense citations (e.g. [1-3, 5, 9]), then bibtex can do at least some of that (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/). Also, I don't know how easy it would be to capture the other features of citations (e.g., the in-text vs. parenthetical distinction) without relying on a package like natbib. If generating BibTeX-compatible LaTeX is needed, is it OK to rely on such a package? IMO yes. Nick
Re: [O] org-cite and org-citeproc
Hi Eric and all, Eric S Fraga e.fr...@ucl.ac.uk writes: On Saturday, 28 Mar 2015 at 10:53, Richard Lawrence wrote: I thought I should send an update to let you know that org-citeproc [1], the command-line citation processing tool I've been working on, now supports multi-cites. I believe that means it is now capable of processing all citations in the basic citation syntax. It can output plain text, HTML, and ODT (and a Pandoc native format, mostly useful for debugging). This looks really good! Thanks. Thanks! However, for some reason, libreoffice doesn't display the citations in the ODT document you have included. I have had a look at the actual ODT file and it looks fine. Can you suggest what may be wrong? Hmm, you're right. I don't have LibreOffice on the machine where I am working on org-citeproc, but I tested it on another machine (OS X, LibreOffice version 4.2.8.2 I think), and the citation text is indeed missing. As you say, the actual file looks fine to me, and it displays correctly on Google Drive (which is where I originally tested the output). So LibreOffice might be where the problem is. That doesn't mean there isn't a problem with org-citeproc, or the ODT exporter, but given that the file looks fine and another viewer handles it correctly, LibreOffice would be my first suspect. I don't really know anything about the ODT format, though. My code more-or-less blindly pastes Pandoc-generated XML into the document during Org ODT export. Can someone who knows more about the format take a look at the file and see if there is some subtle problem I'm not noticing? A second question: what will be required to use the new cite syntax with LaTeX/PDF which will remain my main target for export? I think this needs more discussion, actually. The citation syntax can basically be mapped directly to BibLaTeX syntax, so generating LaTeX that will be processed with BibLaTeX is a simple and straightforward modification to Org's LaTeX exporter, and compiling the exported document should continue to require no external programs except the LaTeX distribution itself. That is, `C-c C-e l whatever' should continue to be all that is needed from a user's perspective, plus or minus some LATEX_HEADER setup. However, there are a couple of other scenarios to think about: 1) Some people may still need to use plain BibTeX. Generating LaTeX that is intended to be processed with BibTeX, as opposed to BibLaTeX, is a little trickier, because (IIUC) BibTeX does not support multi-cite citations. Also, I don't know how easy it would be to capture the other features of citations (e.g., the in-text vs. parenthetical distinction) without relying on a package like natbib. If generating BibTeX-compatible LaTeX is needed, is it OK to rely on such a package? 2) Some people might find it useful *not* to generate LaTeX citation commands, and instead have a tool like org-citeproc process citations instead, with the exporter inserting the rendered output into the document. This could be useful if e.g. you are preparing to submit to a journal that provides a CSL file, but not a BibTeX or BibLaTeX style. If either of these scenarios represents an important use case, it will be more work to implement. I suggest that for now we just target BibLaTeX, but I'd like to hear from other people about whether there's reason to do more than that. Best, Richard
Re: [O] org-cite and org-citeproc
Aloha all,
Nick Dokos ndo...@gmail.com writes:
Richard Lawrence richard.lawre...@berkeley.edu writes:
However, there are a couple of other scenarios to think about:
1) Some people may still need to use plain BibTeX. Generating LaTeX
that is intended to be processed with BibTeX, as opposed to BibLaTeX, is
a little trickier, because (IIUC) BibTeX does not support multi-cite
citations.
I know next to nothing about citations in general, so please bear with
me: if multi-cite support means being able to condense citations (e.g.
[1-3, 5, 9]), then bibtex can do at least some of that
(e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/).
Multiple citations with natbib are limited in the sense that individual
citations within them don't carry pre- and post-notes. BibLaTeX does
away with this restriction.
Also, I don't know how easy it would be to capture the other
features of citations (e.g., the in-text vs. parenthetical distinction)
without relying on a package like natbib. If generating
BibTeX-compatible LaTeX is needed, is it OK to rely on such a package?
IMO yes.
IMO yes, too.
The org-export-cite-add-citation-mode-latex function that Aaron Ecay
wrote allows the author to choose (implicitly) which package to use. I
like this design because it can accommodate new packages without changes
to the Org mode code.
,-
| Your comment inspired me to implement
| org-export-cite-add-citation-mode-latex in the experimental citation
| support I just pushed. So you can do:
|
| (org-export-cite-add-citation-mode-latex tsd
| \\mycitecommand[%s][%s]{%s} \\myparencitecommand[%s][%s]{%s})
|
| Add to your document:
|
| #+CITATION_MODE: tsd
|
| And citations should just work with your chosen commands. I’m sure when
| advanced citation support comes along (whether from subtypes or plists),
| a similarly simple wrapper can be implemented.
`-
I haven't found time to experiment with the citation developments or to
read through the developing code base. Was this feature of Aaron's
experimental support subsequently dropped?
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] org-cite and org-citeproc
On Tuesday, 31 Mar 2015 at 12:13, Richard Lawrence wrote: Hi Eric and all, Eric S Fraga e.fr...@ucl.ac.uk writes: [...] However, for some reason, libreoffice doesn't display the citations in the ODT document you have included. I have had a look at the actual ODT file and it looks fine. Can you suggest what may be wrong? Hmm, you're right. I don't have LibreOffice on the machine where I am working on org-citeproc, but I tested it on another machine (OS X, LibreOffice version 4.2.8.2 I think), and the citation text is indeed missing. Thanks for confirming this. At least it's not me! I hope somebody can figure out what is going on here. [...] A second question: what will be required to use the new cite syntax with LaTeX/PDF which will remain my main target for export? I think this needs more discussion, actually. The citation syntax can basically be mapped directly to BibLaTeX syntax, so generating LaTeX that will be processed with BibLaTeX is a simple and straightforward modification to Org's LaTeX exporter, and compiling the Although I normally use bibtex, I am happy moving to biblatex if it means unifying org's citation approaches. I don't need the extra features (e.g. multicite) in practice but I'm also not attached to bibtex. thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84
Re: [O] org-cite and org-citeproc
Hi Tom and all,
t...@tsdye.com (Thomas S. Dye) writes:
I know next to nothing about citations in general, so please bear with
me: if multi-cite support means being able to condense citations (e.g.
[1-3, 5, 9]), then bibtex can do at least some of that
(e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/).
Multiple citations with natbib are limited in the sense that individual
citations within them don't carry pre- and post-notes. BibLaTeX does
away with this restriction.
Just to clarify: our syntax allows both pre- and post-notes for each
individual reference within a citation, plus common pre- and post-notes
for the citation as a whole. Is it only the latter which BibTeX does
not support? Or is it also that it can't handle pre- and post-notes for
individual references when there is more than one work cited? I don't
think I've ever tried to do something that complicated with plain BibTeX.
(Also, do you think it is important to support plain BibTeX at all? It
seems like we should not bother with this problem unless it's important
for a lot of people. I personally would be fine with just targeting
BibLaTeX, and it sounds like Eric would be too.)
The org-export-cite-add-citation-mode-latex function that Aaron Ecay
wrote allows the author to choose (implicitly) which package to use. I
like this design because it can accommodate new packages without changes
to the Org mode code.
,-
| Your comment inspired me to implement
| org-export-cite-add-citation-mode-latex in the experimental citation
| support I just pushed. So you can do:
|
| (org-export-cite-add-citation-mode-latex tsd
| \\mycitecommand[%s][%s]{%s} \\myparencitecommand[%s][%s]{%s})
|
| Add to your document:
|
| #+CITATION_MODE: tsd
|
| And citations should just work with your chosen commands. I’m sure when
| advanced citation support comes along (whether from subtypes or plists),
| a similarly simple wrapper can be implemented.
`-
I haven't found time to experiment with the citation developments or to
read through the developing code base. Was this feature of Aaron's
experimental support subsequently dropped?
No, I haven't touched that part of the code, and as far as I know that
should still work. However, I also haven't been able to make sense of
how the CITATION_MODE and CITATION_STYLE keywords should work in
non-LaTeX backends, so my code doesn't make any use of them, either.
If I understand correctly, the mode and the style are two pieces of
information that jointly determine how citations should be formatted.
The reason they are separated is that you can have multiple styles
associated with a mode (or is it the other way around?). Is it right to
say that in LaTeX, choosing a mode and a style determines both
which citation commands are available and what their behavior is?
In the CSL world, both of these pieces of information seem to be
determined by the choice of CSL stylesheet. Thus, I went with a single
keyword, CSL_FILE, to specify this information. I guess one could also
go the other way, and try to select a stylesheet based on CITATION_MODE
and CITATION_STYLE, but I wasn't sure how to do that. I also don't
really know if it would be useful to provide a notion of `custom modes'
outside of LaTeX; as far as I can see, all customization would just come
down to selecting a different stylesheet. But maybe I'm missing
something important?
Best,
Richard
Re: [O] org-cite and org-citeproc
Richard Lawrence richard.lawre...@berkeley.edu writes: I don't really know anything about the ODT format, though. My code more-or-less blindly pastes Pandoc-generated XML into the document during Org ODT export. Can someone who knows more about the format take a look at the file and see if there is some subtle problem I'm not noticing? I can't test your code 'cause I, for personal/silly reasons, refuse to spend any more dealing with compiling Haskell. That being said, my gut feeling is that you have to define the data elsewhere. For example, to add a (sub)title to a odt document the field/keyword is defined in a file different from contents.xml and will just not be printed if used in contents.xml only. Also, the bibliography is not correct in the sense that if it was setup in the right semantic way, it would be gray in LO, like the TOC. —Rasmus -- Bang bang
Re: [O] org-cite and org-citeproc
Richard Lawrence richard.lawre...@berkeley.edu writes:
Hi Tom and all,
t...@tsdye.com (Thomas S. Dye) writes:
I know next to nothing about citations in general, so please bear with
me: if multi-cite support means being able to condense citations (e.g.
[1-3, 5, 9]), then bibtex can do at least some of that
(e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/).
Multiple citations with natbib are limited in the sense that individual
citations within them don't carry pre- and post-notes. BibLaTeX does
away with this restriction.
Just to clarify: our syntax allows both pre- and post-notes for each
individual reference within a citation, plus common pre- and post-notes
for the citation as a whole. Is it only the latter which BibTeX does
not support? Or is it also that it can't handle pre- and post-notes for
individual references when there is more than one work cited? I don't
think I've ever tried to do something that complicated with plain BibTeX.
IIUC, plain BibTeX just supports \cite, and it was the natbib style
that introduced parenthetical, \citep, and text, \citet, citation
commands. The corresponding commands in BibLaTeX styles are \parencite
and \textcite.
With natbib, it is possible to give a pre-note and a post-note to the
citation as a whole, but not to individual citations within it. In
order to support your syntax fully, I think BibLaTeX is needed.
(Also, do you think it is important to support plain BibTeX at all? It
seems like we should not bother with this problem unless it's important
for a lot of people. I personally would be fine with just targeting
BibLaTeX, and it sounds like Eric would be too.)
Well, one benefit of Aaron's function was to make this choice
superfluous, both now and in the future. It binds the two citation
commands you've implemented to citation commands implemented in
CITATION_STYLE. As Aaron notes, it should be easy to modify this (to
bind additional commands) when advanced citation support comes along.
The org-export-cite-add-citation-mode-latex function that Aaron Ecay
wrote allows the author to choose (implicitly) which package to use. I
like this design because it can accommodate new packages without changes
to the Org mode code.
,-
| Your comment inspired me to implement
| org-export-cite-add-citation-mode-latex in the experimental citation
| support I just pushed. So you can do:
|
| (org-export-cite-add-citation-mode-latex tsd
| \\mycitecommand[%s][%s]{%s} \\myparencitecommand[%s][%s]{%s})
|
| Add to your document:
|
| #+CITATION_MODE: tsd
|
| And citations should just work with your chosen commands. I’m sure when
| advanced citation support comes along (whether from subtypes or plists),
| a similarly simple wrapper can be implemented.
`-
I haven't found time to experiment with the citation developments or to
read through the developing code base. Was this feature of Aaron's
experimental support subsequently dropped?
No, I haven't touched that part of the code, and as far as I know that
should still work. However, I also haven't been able to make sense of
how the CITATION_MODE and CITATION_STYLE keywords should work in
non-LaTeX backends, so my code doesn't make any use of them, either.
IIUC, CITATION_STYLE refers to the bibliography style file.
CITATION_MODE makes it possible for an author using your syntax to get
away from the Harvard mode citations that seem to be your target and use
another mode such as the footnote citations common in the humanities.
If I understand correctly, the mode and the style are two pieces of
information that jointly determine how citations should be formatted.
The reason they are separated is that you can have multiple styles
associated with a mode (or is it the other way around?). Is it right to
say that in LaTeX, choosing a mode and a style determines both
which citation commands are available and what their behavior is?
Typically, a bibliography style file defines several citation commands,
which might belong to one or more modes. It sounds to me as if the CSL
world conflates styles and modes, but I haven't looked closely.
In the CSL world, both of these pieces of information seem to be
determined by the choice of CSL stylesheet. Thus, I went with a single
keyword,
[O] org-cite and org-citeproc
Hi everyone, I thought I should send an update to let you know that org-citeproc [1], the command-line citation processing tool I've been working on, now supports multi-cites. I believe that means it is now capable of processing all citations in the basic citation syntax. It can output plain text, HTML, and ODT (and a Pandoc native format, mostly useful for debugging). org-citeproc hooks up with the Org exporters via Aaron Ecay's org-cite [2] library, so that it is possible to export a document containing citations as text, HTML, or ODT. A sample Org document, bib file, CSL file, and outputs are attached. I am pretty convinced at this point that the approach that the combination of org-cite and org-citeproc represents is viable, even if org-citeproc is not the tool (or one of the tools) that the Org community eventually adopts. If you'd like to help out with developing it, here are some things that would be useful: 1) If you are comfortable building a Haskell program and running an unstable branch of Org, it would be great to have people test org-cite and org-citeproc with more realistic documents, and with other CSL files. The basic things work, but there are surely many corner cases to be weeded out. 2) If you know Haskell, I would appreciate feedback on the org-citeproc code. I am pretty new to Haskell and suspect there is a lot in my code that could be cleaned up or made more idiomatic. 3) If you know Elisp, there are plenty of things still TODO in org-cite.el. I haven't hacked on this much except to get it working with org-citeproc. 4) I would also be interested in seeing a parallel implementation in org-cite of citation processing via Zotero. I think the infrastructure org-cite provides should make it relatively easy to get something like this working, perhaps in combination with the zotxt plugin. This would provide two benefits: it would help prove the org-cite API is general enough, and it would provide an alternative to org-citeproc for people who already have a CSL implementation (namely Zotero) installed and don't want to build/install a separate Haskell program just to process citations. Here's the code: [1] https://github.com/wyleyr/org-citeproc [2] https://github.com/wyleyr/org-mode (This branch contains the version of org-cite needed to work with org-citeproc.) Thanks for looking! Best, Richard #+OPTIONS: ':nil *:t -:t ::t :t H:3 \n:nil ^:t arch:nil author:t #+OPTIONS: c:nil creator:comment d:(not LOGBOOK) date:t e:t #+OPTIONS: email:nil f:t inline:t num:t p:nil pri:nil prop:nil stat:t #+OPTIONS: tags:t tasks:t tex:t timestamp:t title:t toc:t todo:t |:t #+TITLE: Org-Citeproc tests #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+SELECT_TAGS: export #+EXCLUDE_TAGS: noexport #+CREATOR: Emacs 23.4.1 (Org mode 8.3beta) #+CSL_FILE: chicago-author-date.csl #+BIBDB: bibtex testdoc.bib * Org markup ** Simple citations *** Parenthetical Some great ideas occur in books [@Brandom1994]. Others in articles [@Hofweber2007]. Still others are in collections of previously published work [@Russell1919], or in conference proceedings [@Rogers1996]; sometimes they are the proceedings themselves [@RogersKepser2007]. Sometimes, a great idea can be found in a dissertation [@Caponigro2003], and sometimes on just a handout [@Ross1985]. Some remain forever unpublished [@Faraci1970]. *** In-text Some great ideas occur in books, such as @Brandom1994. Others in articles, such as @Hofweber2007. Still others are in collections of previously published work, such as @Russell1919, or in conference proceedings like @Rogers1996; sometimes they are the proceedings themselves such as @RogersKepser2007. Sometimes, a great idea can be found in a dissertation, such as @Caponigro2003, and sometimes on just a handout like @Ross1985. Some remain forever unpublished, such as @Faraci1970. *** With prefix and suffix data Some great ideas occur in books [(cite): see @Brandom1994 chapter 7]. Others in articles [(cite): @Hofweber2007 section 1]. Still others are in collections of previously published work, such as [cite: @Russell1919 cf. section 3], or in conference proceedings [(cite): e.g., @Rogers1996]. Sometimes, a great idea can be found in a dissertation, like an idea by [cite: see @Caponigro2003 chapter 1], and sometimes on just a handout, like others by [cite: e.g., @Ross1985]. *** Citations to works with tricky field data In some cases, the authors have names which are tricky to represent in BibTeX, like @BelnapSteel1976, or @Vaanaanen2011. @denDikkenMeinungerWilder2000 has a lead author that should probably be capitalized in sentence-initial position. Sometimes, it's the journal name which is difficult [@Belnap1970]. ** Multi-cite citations *** Parenthetical, keys only Some great ideas occur in books, articles, or collections [(cite): @Brandom1994; @Hofweber2007; @Russell1919]. Some occur in conference proceedings or dissertations [(cite): @Rogers1996; @RogersKepser2007; @Caponigro2003], and
