[wip-cite-new] Initial implementation of `csl' citation processor

[wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

I just pushed a Citeproc-based citation processor. As such, Citeproc
library must be available in the load path. For a better experience,
your also need to download styles, and possibly locales definitions, as
pointed in the commentary section pasted below.

I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
is shorter, and "org-cite-csl" prefix sounds less redudant than
"org-cite-citeproc...". Also, I don't expect a different CSL-based
citation processor any time soon, so it should be fine. But I know this
is a weak argument, so if you think "citeproc" is still more
appropriate, I can revisit this.

As pointed out in the commentary section, this is, for a large part,
a port of András Simonyi's Citeproc Org library. Thanks!

There are some differences between the two libraries, however. For
example, Org Cite CSL does not support Org Ref links. It also provides
less customization options. OTOH, it supports ".bib", ".bibtex" and
".json" bibliography files. It also handles author suppression and
global affixes in citations.

This patch adds two files in a new "etc/csl/" directory. They are both
licensed under CC BY-SA 3.0 terms. So I assume this is fine to
distribute them with Org.

Here is the full commentary. Feedback welcome!

--8<---------------cut here---------------start------------->8---
This library registers the `csl' citation processor, which provides
the "export" capability for citations.  You may activate it globally with

   (setq org-cite-export-processor '(csl))

or at the document level, with

   #+cite_export: csl

The processor relies on the external Citeproc Emacs library, which must be
available prior to loading this library.

By default, citations are rendered in Chicago author-date CSL style.  You can
use another style file by specifying it in `org-cite-export-processor'

   (setq org-cite-export-processor '(csl "/path/to/style-file.csl")

or from within the document by adding the file name to "cite_export" keyword

   #+cite_export: csl /path/to/style-file.csl
   #+cite_export: csl "/path/to/style-file.csl"

Styles can be downloaded, for instance, from the Zotero Style Repository
(<https://www.zotero.org/styles>).  Dependent styles (which are not "unique"
in the Zotero Style Repository terminology) are not supported.

The processor uses the "en-US" CSL locale file shipped with Org for rendering
localized dates and terms in the references, independently of the language
settings of the Org document.  Additional CSL locales can be made available
by setting `org-cite-csl-locales-dir' to a directory containing the locale
files in question (see <https://github.com/citation-style-language/locales>
for such files).  The directory must contain at least the "en-US" CSL locale.

Bibliography is defined with the "bibliography" keyword.  It supports files
with ".bib", ".bibtex", and ".json" extensions.  References are exported using
the "print_bibliography" keyword.

The library supports the following citation styles:

- noauthor (na), including bare (b) variant,
- default style, including bare (b) variant.

CSL styles recognize "locator" in citation references' suffix.  For example,
in the citation

    [cite:see @Tarski-1965 chapter 1, for an example]

"chapter 1" is the locator.  The whole citation is rendered as

    (see Tarski 1965, chap. 1 for an example)

in the default CSL style.

The locator starts with a locator term, among "bk.", "bks.", "book", "chap.",
"chaps.", "chapter", "col.", "cols.", "column", "figure", "fig.", "figs.",
"folio", "fol.", "fols.", "number", "no.", "nos.", "line", "l.", "ll.",
"note", "n.", "nn.", "opus", "op.", "opp.", "page", "p.", "pp.", "paragraph",
"para.", "paras.", "¶", "¶¶", "§", "§§", "part", "pt.", "pts.", "section",
"sec.", "secs.", "sub verbo", "s.v.", "s.vv.", "verse", "v.", "vv.",
"volume", "vol.", and "vols.".  It ends with the last comma or digit in the
suffix, whichever comes last, or runs till the end of the suffix.

The part of the suffix before the locator is appended to reference's prefix.
If no locator term is used, but a number is present, then "page" is assumed.

This library was heavily inspired by and borrows from András Simonyi's
Citeproc Org (<https://github.com/andras-simonyi/citeproc-org>) library.
Many thanks to him!
--8<---------------cut here---------------end--------------->8---

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

Hi Nicolas,

I'll take a close look at this and test it over the coming days, but
in the meantime, on two more general points:

On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

First, names:

> I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
> is shorter, and "org-cite-csl" prefix sounds less redudant than
> "org-cite-citeproc...".  But I know this is a weak argument, so if you think "citeproc"
> is still more appropriate, I can revisit this.

From my perspective, that's totally fine, and arguably better: csl
export processor for citeproc library.

The citeproc name is just a convention for the processors that's
developed over time I think mostly because people couldn't be bothered
to come up with better names. I actually wrote the very first one, in
XSLT, called citeproc-xsl.

I think CSL would be more widely known among users though.

And this processor doesn't actually do the formatting, so it makes sense.

Second, this:

> Also, I don't expect a different CSL-based citation processor any time soon, so it should be fine.

Well, I'll ask you the same question I asked Andras recently:

What if a developer has the idea to hook up one of the new, very fast,
csl libraries: either the haskell version associated with pandoc, or
the rust-based version associated with Zotero?

Possible reasons they might want to do that: performance and/or
compliance/features.

Could you make sure this module is coded in such a way that it should
be relatively straightforward to do that?

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> What if a developer has the idea to hook up one of the new, very fast,
> csl libraries: either the haskell version associated with pandoc, or
> the rust-based version associated with Zotero?
>
> Possible reasons they might want to do that: performance and/or
> compliance/features.
>
> Could you make sure this module is coded in such a way that it should
> be relatively straightforward to do that?

The citation processor is pretty much centered around the API provided
by the Emacs Citeproc library. I don't know what interface the other
libraries you mention do provide, but if they are not close to each
other, some work will be required.

Fortunately, barring constants and defcustoms, that's roughly 300 locs.
At this size, doing anything is (or should be) "relatively
straightforward" in Elisp.

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Wed, May 26, 2021 at 6:07 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > What if a developer has the idea to hook up one of the new, very fast,
> > csl libraries: either the haskell version associated with pandoc, or
> > the rust-based version associated with Zotero?
> >
> > Possible reasons they might want to do that: performance and/or
> > compliance/features.
> >
> > Could you make sure this module is coded in such a way that it should
> > be relatively straightforward to do that?
>
> The citation processor is pretty much centered around the API provided
> by the Emacs Citeproc library. I don't know what interface the other
> libraries you mention do provide, but if they are not close to each
> other, some work will be required.

They are close, but ....

> Fortunately, barring constants and defcustoms, that's roughly 300 locs.
> At this size, doing anything is (or should be) "relatively
> straightforward" in Elisp.

... 300 LOC is indeed pretty compact.

BTW, I did get it all setup, and do seem to have run into a bug.

Input:

[cite/noauthor:@latexcompanion p23]

Output (not position of the locator label):

(p 1993, 23)

BTW, I mentioned on the citeproc-el issue tracker that it should be
pretty straightforward to add support for both the "author" and "text"
styles there, and then in turn here:

https://github.com/andras-simonyi/citeproc-el/issues/15

This is because "text" is basically just "author/bare" + "noauthor".

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> BTW, I did get it all setup, and do seem to have run into a bug.
>
> Input:
>
> [cite/noauthor:@latexcompanion p23]
>
> Output (not position of the locator label):
>
> (p 1993, 23)

Hmm ... experimenting some more, these work correctly.

[cite/noauthor:@latexcompanion page 23]
[cite/noauthor:@latexcompanion p. 23]
[cite/noauthor:@latexcompanion p.23]

Still not sure why the above with the p at the front though.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Denis Maier]

Am 27.05.2021 um 03:58 schrieb Bruce D'Arcus:
> On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:
> 
>> BTW, I did get it all setup, and do seem to have run into a bug.
>>
>> Input:
>>
>> [cite/noauthor:@latexcompanion p23]
>>
>> Output (not position of the locator label):
>>
>> (p 1993, 23)
> 
> Hmm ... experimenting some more, these work correctly.
> 
> [cite/noauthor:@latexcompanion page 23]
> [cite/noauthor:@latexcompanion p. 23]
> [cite/noauthor:@latexcompanion p.23]
> 
> Still not sure why the above with the p at the front though.

I think a plain "p" in front of a number is not recognized as a locator 
prefix.
Nicolas's post mentions "page", "p.", "pp." as valid locator terms for 
page. So in your case this here seems to apply: "The part of the suffix 
before the locator is appended to reference's prefix."

Denis
> 
> Bruce
> 
> 

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Denis Maier]

Hi,

Am 26.05.2021 um 22:33 schrieb Nicolas Goaziou:

thanks for this!

I've just tried to test this, but I can't get it to work.

I've done
git pull
make

And I'm getting:
In toplevel form:
oc-csl.el:93:1:Error: Cannot open load file: No such file or directory, 
citeproc

Do you have an idea what's going wrong here?

Best,
Denis

> Hello,
> 
> I just pushed a Citeproc-based citation processor. As such, Citeproc
> library must be available in the load path. For a better experience,
> your also need to download styles, and possibly locales definitions, as
> pointed in the commentary section pasted below.
> 
> I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
> is shorter, and "org-cite-csl" prefix sounds less redudant than
> "org-cite-citeproc...". Also, I don't expect a different CSL-based
> citation processor any time soon, so it should be fine. But I know this
> is a weak argument, so if you think "citeproc" is still more
> appropriate, I can revisit this.
> 
> As pointed out in the commentary section, this is, for a large part,
> a port of András Simonyi's Citeproc Org library. Thanks!
> 
> There are some differences between the two libraries, however. For
> example, Org Cite CSL does not support Org Ref links. It also provides
> less customization options. OTOH, it supports ".bib", ".bibtex" and
> ".json" bibliography files. It also handles author suppression and
> global affixes in citations.
> 
> This patch adds two files in a new "etc/csl/" directory. They are both
> licensed under CC BY-SA 3.0 terms. So I assume this is fine to
> distribute them with Org.
> 
> Here is the full commentary. Feedback welcome!
> 
> --8<---------------cut here---------------start------------->8---
> This library registers the `csl' citation processor, which provides
> the "export" capability for citations.  You may activate it globally with
> 
>     (setq org-cite-export-processor '(csl))
> 
> or at the document level, with
> 
>     #+cite_export: csl
> 
> The processor relies on the external Citeproc Emacs library, which must be
> available prior to loading this library.
> 
> By default, citations are rendered in Chicago author-date CSL style.  You can
> use another style file by specifying it in `org-cite-export-processor'
> 
>     (setq org-cite-export-processor '(csl "/path/to/style-file.csl")
> 
> or from within the document by adding the file name to "cite_export" keyword
> 
>     #+cite_export: csl /path/to/style-file.csl
>     #+cite_export: csl "/path/to/style-file.csl"
> 
> Styles can be downloaded, for instance, from the Zotero Style Repository
> (<https://www.zotero.org/styles>).  Dependent styles (which are not "unique"
> in the Zotero Style Repository terminology) are not supported.
> 
> The processor uses the "en-US" CSL locale file shipped with Org for rendering
> localized dates and terms in the references, independently of the language
> settings of the Org document.  Additional CSL locales can be made available
> by setting `org-cite-csl-locales-dir' to a directory containing the locale
> files in question (see <https://github.com/citation-style-language/locales>
> for such files).  The directory must contain at least the "en-US" CSL locale.
> 
> Bibliography is defined with the "bibliography" keyword.  It supports files
> with ".bib", ".bibtex", and ".json" extensions.  References are exported using
> the "print_bibliography" keyword.
> 
> The library supports the following citation styles:
> 
> - noauthor (na), including bare (b) variant,
> - default style, including bare (b) variant.
> 
> CSL styles recognize "locator" in citation references' suffix.  For example,
> in the citation
> 
>      [cite:see @Tarski-1965 chapter 1, for an example]
> 
> "chapter 1" is the locator.  The whole citation is rendered as
> 
>      (see Tarski 1965, chap. 1 for an example)
> 
> in the default CSL style.
> 
> The locator starts with a locator term, among "bk.", "bks.", "book", "chap.",
> "chaps.", "chapter", "col.", "cols.", "column", "figure", "fig.", "figs.",
> "folio", "fol.", "fols.", "number", "no.", "nos.", "line", "l.", "ll.",
> "note", "n.", "nn.", "opus", "op.", "opp.", "page", "p.", "pp.", "paragraph",
> "para.", "paras.", "¶", "¶¶", "§", "§§", "part", "pt.", "pts.", "section",
> "sec.", "secs.", "sub verbo", "s.v.", "s.vv.", "verse", "v.", "vv.",
> "volume", "vol.", and "vols.".  It ends with the last comma or digit in the
> suffix, whichever comes last, or runs till the end of the suffix.
> 
> The part of the suffix before the locator is appended to reference's prefix.
> If no locator term is used, but a number is present, then "page" is assumed.
> 
> This library was heavily inspired by and borrows from András Simonyi's
> Citeproc Org (<https://github.com/andras-simonyi/citeproc-org>) library.
> Many thanks to him!
> --8<---------------cut here---------------end--------------->8---
> 
> Regards,
> 

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

Denis Maier <denismaier@mailbox.org> writes:

> I've just tried to test this, but I can't get it to work.
>
> I've done
> git pull
> make
>
> And I'm getting:
> In toplevel form:
> oc-csl.el:93:1:Error: Cannot open load file: No such file or
> directory, citeproc
>
> Do you have an idea what's going wrong here?

You need to add the external Citeproc library
(<https://github.com/andras-simonyi/citeproc-el>) to your load path.
Otherwise, the library won't compile.

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 4:01 AM Denis Maier <denismaier@mailbox.org> wrote:
>
> Am 27.05.2021 um 03:58 schrieb Bruce D'Arcus:
> > On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:
> >
> >> BTW, I did get it all setup, and do seem to have run into a bug.
> >>
> >> Input:
> >>
> >> [cite/noauthor:@latexcompanion p23]
> >>
> >> Output (not position of the locator label):
> >>
> >> (p 1993, 23)
> >
> > Hmm ... experimenting some more, these work correctly.
> >
> > [cite/noauthor:@latexcompanion page 23]
> > [cite/noauthor:@latexcompanion p. 23]
> > [cite/noauthor:@latexcompanion p.23]
> >
> > Still not sure why the above with the p at the front though.
>
> I think a plain "p" in front of a number is not recognized as a locator
> prefix.
> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
> page. So in your case this here seems to apply: "The part of the suffix
> before the locator is appended to reference's prefix."

I missed the significance of that last part.

What's the use case there Nicolas?

Aside from that, a bit more testing this morning, with plain, latex
and html is looking good. I got exected output using default and the
chicago-note-bibliography-16th-edition.csl style.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> The processor uses the "en-US" CSL locale file shipped with Org for rendering
> localized dates and terms in the references, independently of the language
> settings of the Org document.  Additional CSL locales can be made available
> by setting `org-cite-csl-locales-dir' to a directory containing the locale
> files in question (see <https://github.com/citation-style-language/locales>
> for such files).  The directory must contain at least the "en-US" CSL locale.

So if I setup a separate directory for different locales files, I also
have to include the default locale that's already shipped with org?

That seems a bit odd.

Related, could we also have a  `org-cite-csl-styles-dir' defcustom, to
avoid having to specify the full path?

And/or alternately just  `org-cite-csl-dir' for both locales and styles?

Also, is it possible for me to set things up so that export to latex
runs through the oc-biblatex processor, but otherwise it uses oc-csl,
where I have (obviously) different styles for each?

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

Denis Maier <denismaier@mailbox.org> writes:

> I think a plain "p" in front of a number is not recognized as
> a locator prefix.
> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
> page. So in your case this here seems to apply: "The part of the
> suffix before the locator is appended to reference's prefix."

That's correct.

I updated the regexp matching locators to handle this case (and others).
So "p23" is now recognized (but not "p23-25" for example).

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> On Thu, May 27, 2021 at 4:01 AM Denis Maier <denismaier@mailbox.org> wrote:

>> I think a plain "p" in front of a number is not recognized as a locator
>> prefix.
>> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
>> page. So in your case this here seems to apply: "The part of the suffix
>> before the locator is appended to reference's prefix."
>
> I missed the significance of that last part.
>
> What's the use case there Nicolas?

This was ported from Citeproc Org library. I don't think there's a use
case, but that information should not be dropped silently, so it's a way
to do "something" about it.

> Aside from that, a bit more testing this morning, with plain, latex
> and html is looking good. I got exected output using default and the
> chicago-note-bibliography-16th-edition.csl style.

Great!

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 9:12 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > On Thu, May 27, 2021 at 4:01 AM Denis Maier <denismaier@mailbox.org> wrote:
>
> >> I think a plain "p" in front of a number is not recognized as a locator
> >> prefix.
> >> Nicolas's post mentions "page", "p.", "pp." as valid locator terms for
> >> page. So in your case this here seems to apply: "The part of the suffix
> >> before the locator is appended to reference's prefix."
> >
> > I missed the significance of that last part.
> >
> > What's the use case there Nicolas?
>
> This was ported from Citeproc Org library. I don't think there's a use
> case, but that information should not be dropped silently, so it's a way
> to do "something" about it.

OK, I guess the question is for Andras then.

I was expecting (not to say I should have necessarily) in this case:

[cite:@doe p23]

... that either "p23" is recognized as a locator, or as a suffix
string for the citation reference.

I'm having a hard time understanding why one would want that "p" to be
added to the prefix.

Andras? Anyone else?

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 10:18 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> I was expecting (not to say I should have necessarily) in this case:
>
> [cite:@doe p23]
>
> ... that either "p23" is recognized as a locator, or as a suffix
> string for the citation reference.

To be clear, Nicolas, your change to the regex this today, however,
does recognize that as a locator, so this specific example is a
non-issue ATM.

I am still curious about the behavior though.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 10:34 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:
>
> On Thu, May 27, 2021 at 10:18 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:
>
> > I was expecting (not to say I should have necessarily) in this case:
> >
> > [cite:@doe p23]
> >
> > ... that either "p23" is recognized as a locator, or as a suffix
> > string for the citation reference.
>
> To be clear, Nicolas, your change to the regex this today, however,
> does recognize that as a locator, so this specific example is a
> non-issue ATM.

Although, users should probably be encouraged to use the "p.1" syntax,
so it's consistent with one or a range.

One other thing I tested just now not yet accounted for: a locator
whose values is a list; for example, that renders as (Doe 2019, pp.
23, 25).

Is there an easy way to handle that?

If not, it would seem even more important to output that as a suffix
string, so users can still get the output they want?

One other question:

Right now, citeproc-el, and hence also oc-csl, only supports the "bare" variant.

Would it be feasible, and make sense, to fall back all "bare" variants
to "bare" for now?

So this:

[cite//bare-caps:@latexcompanion]

... would render as:

Doe 2019

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 11:02 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> One other thing I tested just now not yet accounted for: a locator
> whose values is a list; for example, that renders as (Doe 2019, pp.
> 23, 25).
>
> Is there an easy way to handle that?

Nevermind; this works as expected.

[cite:@latexcompanion p.23, 24]

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

I'm trying to run this on a fairly recent emacs-master w/ native-comp
enable, using  ~emacs -Q ~/test-cites.org~, where test-cites.org is this:

#+cite_export: csl
"/home/matt/Zotero/styles/chicago-manual-of-style-16th-edition-inline-notes-for-syllabi.csl"
#+bibliography: /home/matt/.emacs.d/zotero-refs.bib
#+begin_src emacs-lisp
  (package-initialize)
  (add-to-list 'package-archives
      '("melpa" . "https://melpa.org/packages/"))
  (add-to-list 'load-path "~/src/org-mode/emacs/site-lisp/org")

  (org-reload)
  (add-to-list 'load-path "~/src/org-mode/lisp")
  (require 'oc)
  (require 'citeproc)
  (require 'oc-csl)
#+end_src

[cite:@zittrain_future_2008]

trying to execute the src block gives me a segfault on org-reload, with
different messages each time. Any idea how I should diagnose, or am I
perhaps doing something wrong?

On Thu, May 27, 2021 at 12:18 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:

> On Thu, May 27, 2021 at 11:02 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:
>
> > One other thing I tested just now not yet accounted for: a locator
> > whose values is a list; for example, that renders as (Doe 2019, pp.
> > 23, 25).
> >
> > Is there an easy way to handle that?
>
> Nevermind; this works as expected.
>
> [cite:@latexcompanion p.23, 24]
>
> Bruce
>
>

[-- Attachment #2: Type: text/html, Size: 2025 bytes --]

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Thu, May 27, 2021 at 12:13 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:
>
> On Thu, May 27, 2021 at 11:02 AM Bruce D'Arcus <bdarcus@gmail.com> wrote:
>
> > One other thing I tested just now not yet accounted for: a locator
> > whose values is a list; for example, that renders as (Doe 2019, pp.
> > 23, 25).
> >
> > Is there an easy way to handle that?
>
> Nevermind; this works as expected.
>
> [cite:@latexcompanion p.23, 24]

Pandoc has an option to surround more complex locators, that might
confuse the parser, in braces.

More:

https://pandoc.org/MANUAL.html#extension-citations

Is that feasible here too?

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> Pandoc has an option to surround more complex locators, that might
> confuse the parser, in braces.
>
> More:
>
> https://pandoc.org/MANUAL.html#extension-citations
>
> Is that feasible here too?

I'd like to avoid this if possible. We'll see what we can do when we
encounter such cases.

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
>> The processor uses the "en-US" CSL locale file shipped with Org for rendering
>> localized dates and terms in the references, independently of the language
>> settings of the Org document.  Additional CSL locales can be made available
>> by setting `org-cite-csl-locales-dir' to a directory containing the locale
>> files in question (see <https://github.com/citation-style-language/locales>
>> for such files).  The directory must contain at least the "en-US" CSL locale.
>
> So if I setup a separate directory for different locales files, I also
> have to include the default locale that's already shipped with org?
>
> That seems a bit odd.

Yes, it seems so. I think I fixed it. You may want to update.

> Related, could we also have a  `org-cite-csl-styles-dir' defcustom, to
> avoid having to specify the full path?

Good idea. Also implemented.
>
> And/or alternately just  `org-cite-csl-dir' for both locales and
> styles?

I'd rather keep the two directories separate.

> Also, is it possible for me to set things up so that export to latex
> runs through the oc-biblatex processor, but otherwise it uses oc-csl,
> where I have (obviously) different styles for each?

It is not possible to set export processor per export back-end, but you
can set your more common processor in `org-cite-export-processor' and
use a different "cite_proc" keyword when you need it (and comment it
when you don't).

Is that tolerable?

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Fri, May 28, 2021 at 11:54 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> > Related, could we also have a  `org-cite-csl-styles-dir' defcustom, to
> > avoid having to specify the full path?
>
> Good idea. Also implemented.

Thank you!

> > And/or alternately just  `org-cite-csl-dir' for both locales and
> > styles?
>
> I'd rather keep the two directories separate.

No problem.

> > Also, is it possible for me to set things up so that export to latex
> > runs through the oc-biblatex processor, but otherwise it uses oc-csl,
> > where I have (obviously) different styles for each?
>
> It is not possible to set export processor per export back-end, but you
> can set your more common processor in `org-cite-export-processor' and
> use a different "cite_proc" keyword when you need it (and comment it
> when you don't).
>
> Is that tolerable?

I asked this question because a) I'm not that familiar with the org
export system, and b) I can imagine users wondering about this.

Is this the sort of thing that could be done in an automated batch
process (Is that what "publishing" is for)?

If not, it's "tolerable" for me; as in, maybe not ideal, but also
probably not worth the hassle adding support for at this point if it
indeed is a hassle for you.

But I would primarily use oc-csl, which will export to all formats.
So I don't see it as a big issue.

Not sure about someone that mostly uses oc-biblatex, but also wants to
get HTML output using oc-csl.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Timothy]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> Also, is it possible for me to set things up so that export to latex
>> runs through the oc-biblatex processor, but otherwise it uses oc-csl,
>> where I have (obviously) different styles for each?
>
> It is not possible to set export processor per export back-end, but you
> can set your more common processor in `org-cite-export-processor' and
> use a different "cite_proc" keyword when you need it (and comment it
> when you don't).

Forgive me if I'm jumping in without a good understanding of the
context, but does this mean that I can't easily have biblatex be used
when exporting to .tex and citeproc used when exporting to HTML?

--
Timothy

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

Timothy <tecosaur@gmail.com> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>>> Also, is it possible for me to set things up so that export to latex
>>> runs through the oc-biblatex processor, but otherwise it uses oc-csl,
>>> where I have (obviously) different styles for each?
>>
>> It is not possible to set export processor per export back-end, but you
>> can set your more common processor in `org-cite-export-processor' and
>> use a different "cite_proc" keyword when you need it (and comment it
>> when you don't).
>
> Forgive me if I'm jumping in without a good understanding of the
> context, but does this mean that I can't easily have biblatex be used
> when exporting to .tex and citeproc used when exporting to HTML?

It depends on what you mean by "easily". 

You can, for example, select the appropriate citation processor
according to `org-export-current-backend' in an export hook.

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Timothy]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> Forgive me if I'm jumping in without a good understanding of the
>> context, but does this mean that I can't easily have biblatex be used
>> when exporting to .tex and citeproc used when exporting to HTML?
>
> It depends on what you mean by "easily".

Well, what I'm hoping for from org-cite is that the above behaviour
will, or trivially can, happen automatically. Particularly as I imagine
this wouldn't be an uncommon workflow.

> You can, for example, select the appropriate citation processor
> according to `org-export-current-backend' in an export hook.

I see, this sounds like not too much trouble, but I think ideally this
would be OOTB behaviour.

--
Timothy

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> You can, for example, select the appropriate citation processor
>> according to `org-export-current-backend' in an export hook.
>
> I see, this sounds like not too much trouble, but I think ideally this
> would be OOTB behaviour.

I wouldn't hold my breath. 

First, IIUC, there's no reason to force biblatex over natbib OOTB as
both are widely in use. But, more importantly, "oc-csl" require the
external Citeproc library, so it cannot be loaded by default. As
a consequence, no default configuration can use it.

Regards,

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Timothy]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I wouldn't hold my breath.
>
> First, IIUC, there's no reason to force biblatex over natbib OOTB as
> both are widely in use. But, more importantly, "oc-csl" require the
> external Citeproc library, so it cannot be loaded by default. As
> a consequence, no default configuration can use it.

If you don't mind some follow-up questions.
+ I take it that natbib is used by default for LaTeX then? Is it fairly
  easy for the user to switch to biblatex?
+ With citeproc, I don't suppose something could be put behind a
  (featurep) switch to use oc-csl if citeproc is available, and fall
  back gracefully otherwise?

--
Timothy

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Fri, May 28, 2021 at 1:54 PM Timothy <tecosaur@gmail.com> wrote:
>
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
> > I wouldn't hold my breath.
> >
> > First, IIUC, there's no reason to force biblatex over natbib OOTB as
> > both are widely in use. But, more importantly, "oc-csl" require the
> > external Citeproc library, so it cannot be loaded by default. As
> > a consequence, no default configuration can use it.
>
> If you don't mind some follow-up questions.
> + I take it that natbib is used by default for LaTeX then? Is it fairly
>   easy for the user to switch to biblatex?
> + With citeproc, I don't suppose something could be put behind a
>   (featurep) switch to use oc-csl if citeproc is available, and fall
>   back gracefully otherwise?

Not sure about generally (Nicolas can comment on that), but in this
case, if you specify this:

#+cite_export: natbib

... the export process runs through that processor, even if you are
outputting to plain text or HTML, where natbib is not supported.

So in an HTML file, you end up with citations like "\citet{doe}" of course.

That's actually good for testing, but maybe not so much for actual use.

If you choose oc-biblatex instead, not sure what happens behind the
scenes, but it does export a latex file for biblatex, without any
other configuration, but the same way as with oc-natbib.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> On Fri, May 28, 2021 at 1:54 PM Timothy <tecosaur@gmail.com> wrote:
>>
>>
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>> > I wouldn't hold my breath.
>> >
>> > First, IIUC, there's no reason to force biblatex over natbib OOTB as
>> > both are widely in use. But, more importantly, "oc-csl" require the
>> > external Citeproc library, so it cannot be loaded by default. As
>> > a consequence, no default configuration can use it.
>>
>> If you don't mind some follow-up questions.
>> + I take it that natbib is used by default for LaTeX then? Is it fairly
>>   easy for the user to switch to biblatex?
>> + With citeproc, I don't suppose something could be put behind a
>>   (featurep) switch to use oc-csl if citeproc is available, and fall
>>   back gracefully otherwise?
>
> Not sure about generally (Nicolas can comment on that), but in this
> case, if you specify this:
>
> #+cite_export: natbib
>
> ... the export process runs through that processor, even if you are
> outputting to plain text or HTML, where natbib is not supported.

Exactly.

By default, no export processor is selected. All citations are removed
from output, and print_bibliography keywords, ignored.

You have to actively select what processor you want for the document,
globally, through a variable, or with a cite_export keyword. Therefore,
the processor does not depend on the back-end used; you are supposed to
choose the one you think to be appropriate. There is no falling back
either. You get what you asked for. That's the way.

It could be possible to change `org-cite-export-processor' so it becomes
an alist where you can associate back-ends to processors. But I can't
see how to transpose it nicely to cite_export keyword. 

I'm not convinced this would be an improvement either. For example, you
may want to use two different processors with the same back-end.

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[András Simonyi]

Dear All,

I'm trying to catch up  with the new developments, it isn't easy :-).
I think it would be really helpful to be able to map different
backends to different processors, because latex based solutions like
natbib can handle only latex-based backends, so anybody who wanted to
export both to latex (with a latex citation processor) and something
else would need to constantly change the used citation processor.
Maybe instead of a full alist mapping backends to citation processors
we could have only options to declare a separate processor for
latex-based backends and another for non-latex ones?

best regards,
András

On Fri, 28 May 2021 at 21:41, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > On Fri, May 28, 2021 at 1:54 PM Timothy <tecosaur@gmail.com> wrote:
> >>
> >>
> >> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> >>
> >> > I wouldn't hold my breath.
> >> >
> >> > First, IIUC, there's no reason to force biblatex over natbib OOTB as
> >> > both are widely in use. But, more importantly, "oc-csl" require the
> >> > external Citeproc library, so it cannot be loaded by default. As
> >> > a consequence, no default configuration can use it.
> >>
> >> If you don't mind some follow-up questions.
> >> + I take it that natbib is used by default for LaTeX then? Is it fairly
> >>   easy for the user to switch to biblatex?
> >> + With citeproc, I don't suppose something could be put behind a
> >>   (featurep) switch to use oc-csl if citeproc is available, and fall
> >>   back gracefully otherwise?
> >
> > Not sure about generally (Nicolas can comment on that), but in this
> > case, if you specify this:
> >
> > #+cite_export: natbib
> >
> > ... the export process runs through that processor, even if you are
> > outputting to plain text or HTML, where natbib is not supported.
>
> Exactly.
>
> By default, no export processor is selected. All citations are removed
> from output, and print_bibliography keywords, ignored.
>
> You have to actively select what processor you want for the document,
> globally, through a variable, or with a cite_export keyword. Therefore,
> the processor does not depend on the back-end used; you are supposed to
> choose the one you think to be appropriate. There is no falling back
> either. You get what you asked for. That's the way.
>
> It could be possible to change `org-cite-export-processor' so it becomes
> an alist where you can associate back-ends to processors. But I can't
> see how to transpose it nicely to cite_export keyword.
>
> I'm not convinced this would be an improvement either. For example, you
> may want to use two different processors with the same back-end.
>

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Fri, May 28, 2021 at 9:52 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > Pandoc has an option to surround more complex locators, that might
> > confuse the parser, in braces.
> >
> > More:
> >
> > https://pandoc.org/MANUAL.html#extension-citations
> >
> > Is that feasible here too?
>
> I'd like to avoid this if possible. We'll see what we can do when we
> encounter such cases.

OK; that's fine.

I do want to make you aware of something planned for the next major
version of CSL; both the json input format, and the styling spec:

Multi-part locators, like "chapter 4, pages 23-24".

No point in worrying about it now, but it could impact how you think
about some details now.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Stefan Nobis]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> By default, no export processor is selected. All citations are
> removed from output, and print_bibliography keywords, ignored.

As I'm coming from LaTeX and have been bitten more than once by
missing citations in the output (which is solved far better today by
biblatex), I would say this is not a very good default.

Citations should never be removed (or only with quite some effort). If
you publish a text where citations have been removed by accident,
that's asking for much trouble.

Therefore I would suggest to set some sensible default that at least
does not remove citations. For example a simple ASCII export with
number or author-year style could be the default citation export for
all back-ends. For quite some users (e.g. non-academic, internal
white-papers etc.) this may be also a "good enough" solution, so they
get easy citation support OOTB.

Everyone else would choose some more sophisticated back-end.

> It could be possible to change `org-cite-export-processor' so it
> becomes an alist where you can associate back-ends to processors.
> But I can't see how to transpose it nicely to cite_export keyword.

What about "cite_export" for a single/default export engine and
"cite_export_<backend>" (with "<backend>" something like "html",
"latex", "md", etc.) for overriding the citation exporter for the
given back-end, e.g.

cite_export ascii
cite_export_latex biblatex chicago
cite_export_html csl "some style"

(I forgot about the correct syntax for cite_export, so just a really
rough sketch to illustrate the idea).

Would that be feasible?

> I'm not convinced this would be an improvement either. For example,
> you may want to use two different processors with the same back-end.

I'm not sure if this is true for many back-ends. Currently, I would
assume that this is only the case for the LaTeX back-end (e.g.
preparing a paper for different journals with different citations
requirements). But in this case LaTeX has already quite some tools
that could be utilized. All the different kinds of citation commands
are there to be able to easily switch styles for the whole document
(within a single back-end).

I think what I'm trying to say is, that for the simple Org user it may
be easier to handle peculiarities of his back-ends (like HTML and
LaTeX) that it is for him to write custom Elisp to use exporter A for
HTML and exporter B for LaTeX.

-- 
Until the next mail...,
Stefan.

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Fri, May 28, 2021 at 4:31 PM András Simonyi <andras.simonyi@gmail.com> wrote:

> Maybe instead of a full alist mapping backends to citation processors
> we could have only options to declare a separate processor for
> latex-based backends and another for non-latex ones?

This would go a long way, and is probably all that's necessary.

Really "latex" is the unique output mode here.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 3:51 AM Stefan Nobis <stefan-ml@snobis.de> wrote:
>
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
> > By default, no export processor is selected. All citations are
> > removed from output, and print_bibliography keywords, ignored.
>
> As I'm coming from LaTeX and have been bitten more than once by
> missing citations in the output (which is solved far better today by
> biblatex), I would say this is not a very good default.
>
> Citations should never be removed (or only with quite some effort). If
> you publish a text where citations have been removed by accident,
> that's asking for much trouble.
>
> Therefore I would suggest to set some sensible default that at least
> does not remove citations. For example a simple ASCII export with
> number or author-year style could be the default citation export for
> all back-ends. For quite some users (e.g. non-academic, internal
> white-papers etc.) this may be also a "good enough" solution, so they
> get easy citation support OOTB.
>
> Everyone else would choose some more sophisticated back-end.
>
> > It could be possible to change `org-cite-export-processor' so it
> > becomes an alist where you can associate back-ends to processors.
> > But I can't see how to transpose it nicely to cite_export keyword.
>
> What about "cite_export" for a single/default export engine and
> "cite_export_<backend>" (with "<backend>" something like "html",
> "latex", "md", etc.) for overriding the citation exporter for the
> given back-end, e.g.
>
> cite_export ascii
> cite_export_latex biblatex chicago
> cite_export_html csl "some style"
>
> (I forgot about the correct syntax for cite_export, so just a really
> rough sketch to illustrate the idea).
>
> Would that be feasible?

This is similar to what Andras was suggesting, though his suggestion
is even simpler, because it would only have one for latex; so just
default and latex.

I think that's all we need.

> > I'm not convinced this would be an improvement either. For example,
> > you may want to use two different processors with the same back-end.
>
> I'm not sure if this is true for many back-ends. Currently, I would
> assume that this is only the case for the LaTeX back-end (e.g.
> preparing a paper for different journals with different citations
> requirements). But in this case LaTeX has already quite some tools
> that could be utilized. All the different kinds of citation commands
> are there to be able to easily switch styles for the whole document
> (within a single back-end).

To review, for people that may not be that familiar with CSL, in particular.

LaTeX does all that, with the major limitation that it doesn't do
HTML, docx, rtf, etc.

CSL with citeproc-el does LaTeX (completely bypassing
bibtex/biblatex), and plain text and HTML, and implementations like
pandoc, also do docs, rtf, etc.

So even LaTeX users would likely still want to have oc-csl as their
default processor, for when they want to export to HTML or plain text.

Some, or even many, LaTeX users would prefer to use oc-natib or
oc-biblatex for primary latex export though.

I'm not convinced it's necessary or useful to separately configure for
plain text vs HTML.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> On Fri, May 28, 2021 at 4:31 PM András Simonyi <andras.simonyi@gmail.com> wrote:
>
>> Maybe instead of a full alist mapping backends to citation processors
>> we could have only options to declare a separate processor for
>> latex-based backends and another for non-latex ones?
>
> This would go a long way, and is probably all that's necessary.
>
> Really "latex" is the unique output mode here.

But one may want to use a different processor for, say, beamer and
regular latex. Both are "latex" based. Worse, all custom back-ends
derived from "latex" are bound to use the same processor.

Here's another proposal:

`org-cite-export-processor' is now an alist, where keys are export
back-ends or t, which is the default key.

  '((latex biblatex bibstyle citestyle)
    (beamer natbib nil nil)
    (my-latex natbib bibstyle)
    (t csl nil nil))

The selected processor is the one associated to the back-ends closest to
the current one used for export, by `org-export-derived-backend-p'
order. So if `my-other-latex' is derived from beamer, it will use
(natbib nil nil).

OTOH, I suggest to stick to a single "cite_export" keyword, which
overrides any selected processor above. IOW

   #+cite_export: basic

will use basic whatever the current export back-end is.

In practice, I think it is sufficient. The only case where it may be
limiting is if you need to export with two different back-ends with two
processors different from those set in `org-cite-export-processor'. But
in that situation, I think swapping the cite_export keyword is
acceptable.

So overall, I think it is a good compromise between simplicity and
power.

WDYT?

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> Right now, citeproc-el, and hence also oc-csl, only supports the "bare" variant.
>
> Would it be feasible, and make sense, to fall back all "bare" variants
> to "bare" for now?
>
> So this:
>
> [cite//bare-caps:@latexcompanion]
>
> ... would render as:
>
> Doe 2019

We dropped variant inheritance some time ago already, when the suggested
syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
totally different from Org Cite POV. I'd rather not re-introduce this.

Maybe "bare" need to be promoted as a full-fledged style, so "bare/caps"
could fallback to "bare". I don't know.

Regards,

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 12:34 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > Right now, citeproc-el, and hence also oc-csl, only supports the "bare" variant.
> >
> > Would it be feasible, and make sense, to fall back all "bare" variants
> > to "bare" for now?
> >
> > So this:
> >
> > [cite//bare-caps:@latexcompanion]
> >
> > ... would render as:
> >
> > Doe 2019
>
> We dropped variant inheritance some time ago already, when the suggested
> syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
> totally different from Org Cite POV. I'd rather not re-introduce this.

Oh wait, I just realized citeproc-el already has a parameter for
"caps" (which I hadn't realized).

- "bare" -> "suppress-affixes" parameter
- "caps" -> "capitalize-first"

Right?

So that would allows support for:

- "bare"
- "caps"
- "bare-caps"

So if he adds an equivalent of the "full" parameter, that could extend
the sub-styles support in oc-csl?

> Maybe "bare" need to be promoted as a full-fledged style, so "bare/caps"
> could fallback to "bare". I don't know.

I thought of that too, but it won't work, because "bare" applies to
multiple styles.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 1:25 PM Bruce D'Arcus <bdarcus@gmail.com> wrote:
>
> On Sat, May 29, 2021 at 12:34 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> > We dropped variant inheritance some time ago already, when the suggested
> > syntax was style/variant/subvariant... Now, "bare" and "bare-caps" are
> > totally different from Org Cite POV. I'd rather not re-introduce this.
>
> Oh wait, I just realized citeproc-el already has a parameter for
> "caps" (which I hadn't realized).
>
> - "bare" -> "suppress-affixes" parameter
> - "caps" -> "capitalize-first"
>
> Right?
>
> So that would allows support for:
>
> - "bare"
> - "caps"
> - "bare-caps"
>
> So if he adds an equivalent of the "full" parameter, that could extend
> the sub-styles support in oc-csl?

I added an issue for this at the citeproc-el issue tracker:

https://github.com/andras-simonyi/citeproc-el/issues/16

Note that one key difference with oc-csl is the variants are
configured with individual parameters, while LaTeX uses commands.

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> Oh wait, I just realized citeproc-el already has a parameter for
> "caps" (which I hadn't realized).
>
> - "bare" -> "suppress-affixes" parameter
> - "caps" -> "capitalize-first"
>
> Right?
>
> So that would allows support for:
>
> - "bare"
> - "caps"
> - "bare-caps"

Correct. I added support for the three style variants.

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sat, May 29, 2021 at 12:22 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > On Fri, May 28, 2021 at 4:31 PM András Simonyi <andras.simonyi@gmail.com> wrote:
> >
> >> Maybe instead of a full alist mapping backends to citation processors
> >> we could have only options to declare a separate processor for
> >> latex-based backends and another for non-latex ones?
> >
> > This would go a long way, and is probably all that's necessary.
> >
> > Really "latex" is the unique output mode here.
>
> But one may want to use a different processor for, say, beamer and
> regular latex. Both are "latex" based. Worse, all custom back-ends
> derived from "latex" are bound to use the same processor.

I indeed hadn't thought about that.

> Here's another proposal:
>
> `org-cite-export-processor' is now an alist, where keys are export
> back-ends or t, which is the default key.
>
>   '((latex biblatex bibstyle citestyle)
>     (beamer natbib nil nil)
>     (my-latex natbib bibstyle)
>     (t csl nil nil))
>
> The selected processor is the one associated to the back-ends closest to
> the current one used for export, by `org-export-derived-backend-p'
> order. So if `my-other-latex' is derived from beamer, it will use
> (natbib nil nil).
>
> OTOH, I suggest to stick to a single "cite_export" keyword, which
> overrides any selected processor above. IOW
>
>    #+cite_export: basic
>
> will use basic whatever the current export back-end is.
>
> In practice, I think it is sufficient. The only case where it may be
> limiting is if you need to export with two different back-ends with two
> processors different from those set in `org-cite-export-processor'. But
> in that situation, I think swapping the cite_export keyword is
> acceptable.
>
> So overall, I think it is a good compromise between simplicity and
> power.
>
> WDYT?

I'm not the best person to weigh in on org details, but in general, it
looks good to me.

Just to confirm, then, this would allow me to specify:

1. oc-csl as default
2. oc-biblatex as default for latex
3. locally override

With 3, if on a particular document I didn't want 2, I'd just do this
in the document, which would suppress 2 in effect?

#+cite_export: csl style

...?

Would you have this nil by default, or is there a reasonable default
you could set?

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <bdarcus@gmail.com> writes:

> Just to confirm, then, this would allow me to specify:
>
> 1. oc-csl as default
> 2. oc-biblatex as default for latex
> 3. locally override
>
> With 3, if on a particular document I didn't want 2, I'd just do this
> in the document, which would suppress 2 in effect?
>
> #+cite_export: csl style
>
> ...?

Correct.

> Would you have this nil by default, or is there a reasonable default
> you could set?

I wrote "oc-basic" to be a reasonable, albeit very limited, default.
I just need to make it grow JSON support first.

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[András Simonyi]

Dear All,

On Sat, 29 May 2021 at 18:22, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Here's another proposal:
>
> `org-cite-export-processor' is now an alist, where keys are export
> back-ends or t, which is the default key.
>
>   '((latex biblatex bibstyle citestyle)
>     (beamer natbib nil nil)
>     (my-latex natbib bibstyle)
>     (t csl nil nil))
> The selected processor is the one associated to the back-ends closest to
> the current one used for export, by `org-export-derived-backend-p'
> order. So if `my-other-latex' is derived from beamer, it will use
> (natbib nil nil).

This looks perfect.

> OTOH, I suggest to stick to a single "cite_export" keyword, which
> overrides any selected processor above. IOW
>
>    #+cite_export: basic
>
> will use basic whatever the current export back-end is.
>
> In practice, I think it is sufficient. The only case where it may be
> limiting is if you need to export with two different back-ends with two
> processors different from those set in `org-cite-export-processor'. But
> in that situation, I think swapping the cite_export keyword is
> acceptable.
>
> So overall, I think it is a good compromise between simplicity and
> power.

> WDYT?

I agree, can be revisited later if necessary, but seems to be  a very
strong starting point -- thanks.

best regards,
András

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Sun, May 30, 2021 at 4:20 PM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> > Would you have this nil by default, or is there a reasonable default
> > you could set?
>
> I wrote "oc-basic" to be a reasonable, albeit very limited, default.
> I just need to make it grow JSON support first.

It might not line up with your timeline for this, , and I'm not sure
if you want to depend on an external library, but you should probably
be aware of the work that Joost is doing on parsebib to integrate CSL
JSON support.

The branch, including documentation:

https://github.com/joostkremers/parsebib/tree/wip/csl

Feedback etc:

https://github.com/joostkremers/parsebib/issues/12

Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Here's another proposal:
>
> `org-cite-export-processor' is now an alist, where keys are export
> back-ends or t, which is the default key.
>
>   '((latex biblatex bibstyle citestyle)
>     (beamer natbib nil nil)
>     (my-latex natbib bibstyle)
>     (t csl nil nil))
>
> The selected processor is the one associated to the back-ends closest to
> the current one used for export, by `org-export-derived-backend-p'
> order. So if `my-other-latex' is derived from beamer, it will use
> (natbib nil nil).
>
> OTOH, I suggest to stick to a single "cite_export" keyword, which
> overrides any selected processor above. IOW
>
>    #+cite_export: basic
>
> will use basic whatever the current export back-end is.

I forgot to mention I had implemented the above already.

The default value is:

  ((t basic))