[Top][All Lists]

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

Re: wip-cite status question and feedback

From: Denis Maier
Subject: Re: wip-cite status question and feedback
Date: Wed, 29 Apr 2020 11:14:16 +0200


Am 25.04.2020 um 18:19 schrieb Nicolas Goaziou:

I cannot answer all open questions as the thread would spread too thin.
So, I'll try to subsume where Org is at the moment, and what need to be

Thanks for the suggestion. Looks like a pretty solid approach.

There is a limitation for prefixes and suffixes: they cannot contain
semicolons or closing square brackets. I'm not sure it is worth
implementing some character escape mechanism, tho.

What about using quotes if someone needs this, like so [cite: "common prefix; still common prefix"; pre @key post; pre @key2 post; common suffix] ?

Now with styles:

   [cite/style: ...]
   [cite/style/substyle: ...]
   [cite/mycitationprocessor/fullcite: ...]
   [cite/foot/text: ...]
   [cite/style/substyle/subsubstyle/OMG: ...]

The forward slash separator gives us local citation style and a name
space. There's no limit on the depth of sub-styles. However style
strings are limited to alphanumeric characters only.

Good solution.

I assume [cite:...] is the default citation style, defined at the
citation processor's level. Styled citations override locally the
default style. Again, a processor not handling a given style is expected
to fallback to default style.

As a consequence, there is no special syntax for "author-in-text" style.
But we can suggest one for back-end processors. We might want to stick
to the most complete one, BibLaTeX, IIUC, and /require/ processors to
support, at least:

   [cite/text: ...]
   [cite/paren: ...]

With this bare minimum, we ensure documents are somehow portable between
processors, and, therefore, export back-ends.

Hopefully we can
move onto the next step: how should we interface citation processors and

First, I think we agreed on the BIBLIOGRAPHY keyword, with the following

   #+BIBLIOGRAPHY: "file"

There can be multiple BIBLIOGRAPHY keywords in a document (and
equivalent node properties). Also, I think Org should support a global
variable, e.g., `org-citation-default-bibliography'.

I also think we defined a keyword to insert a bibliography:

   #+PRINT_BIBLIOGRAPHY: ... options ... (may be specific to citation 

Looks good.

- Export ::

   In this case, we may want to allow multiple processors for various
   export back-ends. I thought about declaring active processors in
   a document with a keyword, e.g.,

     #+CITATION_PROCESSOR: org-ref :default-style foo :back-ends (latex)
     #+CITATION_PROCESSOR: citeproc :default-style bar

   and with a global variable, e.g., `org-citation-export-default' which
   could be, e.g.,

     '((default :defaut-style "authoryear" :back-ends (latex)))

   but could become, with appropriate libraries

     '((org-ref :defaut-style "authoryear" :back-ends (latex))
       (citeproc-org :default-style "style-file.csl" :back-ends nil))

   where more specialized back-ends are used first. Note that `latex'
   would mean `latex' and derived back-ends, e.g., `beamer'.

Well, that's all for now. Again, I am not a citation specialist, so
I need feedback. Let's keep the ball rolling!

Does that mean you'll be able to have the same or different processors for different backends? (Like biblatex for latex and citeproc-el for ODT/HTML/etc.; or when you need identical output you can use citeproc-el even for latex?)

Again, thanks for all your work here.

All the best,


reply via email to

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