emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [wip-cite-new] New natbib processor


From: Bruce D'Arcus
Subject: Re: [wip-cite-new] New natbib processor
Date: Thu, 6 May 2021 08:56:41 -0400

On Thu, May 6, 2021 at 8:29 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" <bdarcus@gmail.com> writes:
>
> > The question comes down to whether to support sub-styles or not, and
> > if yes, what the syntax should be.
> >
> > I think it makes more sense to include them because otherwise you end
> > up with an insanely long list of styles, which won't map well onto
> > different kinds of output formats.
>
> I think only oc-citeproc (and oc-basic) may be targetting multiple
> output formats. I doubt it would even use styles; I assume that is
> entirely determined by the CSL file.

Actually, no; it's determined (mostly) by the processor.

A CSL style defines a single default citation layout, which the
processor modifies depending on what variants it supports.

So most of them support a citet-like option, but it's currently
implemented in the processor; not the style.

> > E.g. biblatex users will want like 20 commands available, which won't
> > all work with other formats.
>
> So you would have 20 styles, with shortcuts for the most commons. This
> is not insane, and the mapping is done only once.

In the UI I'm working on for inserting org-cite citations, I have the
small handful of styles, that users can complete.

https://github.com/bdarcus/bibtex-actions/pull/113

It's simple, and clean; the list of style fits on a single line.

Aside: no, I'm not currently planning to include sub-styles here; was
thinking to allow users to add them after if needed. But that could
change of course.

These will work across the different output formats we've discussed,
so I don't need to add different config options for different targets,
and user documents don't have to change to accommodate them.

> Styles do not need to be compatible between processors. As a reminder,
> there's the "fallback rule". According to it, each processor must:
> - provide a default styles;
> - map any unknown style to the style above.

OK, but that is only a single required default style then.

...

> > Even if not perfect, I think it's a small price to pay for the
> > benefits.
>
> I'm still not convinced by the benefits. Could you describe a situation
> where sub-styles would be really beneficial?

Say a natbib user has a document, maybe even a book, that makes common
use of the text style + some examples of sub-styles.

They want to export that document to both HTML and to PDF.

Using styles + sub-styles means she can use the same source to get
both; the first using the citeproc-org processor, and the second
oc-natbib.

Admittedly, a long list of flat styles could still accommodate this (I
think), but I go back to my UI and config point above.

Do note my suggestion on the previous message that we could simplify
sub-styles and still get these benefits. I do agree it's not necessary
to treat sub-styles as an unordered list.

WDYT of that?

Bruce



reply via email to

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