emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Bruce D'Arcus" <bdarcus@gmail.com>
To: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [wip-cite-new] New natbib processor
Date: Thu, 6 May 2021 08:56:41 -0400	[thread overview]
Message-ID: <CAF-FPGPFQmuN3YNE08EtFFhV=ybZ101nkke-0SCBE1k2EbxfEA@mail.gmail.com> (raw)
In-Reply-To: <87sg302ggn.fsf@nicolasgoaziou.fr>

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	other threads:[~2021-05-06 12:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-05 14:53 Nicolas Goaziou
2021-05-05 15:20 ` Bruce D'Arcus
2021-05-05 15:32   ` Bastien
2021-05-06 12:29   ` Nicolas Goaziou
2021-05-06 12:56     ` Bruce D'Arcus [this message]
2021-05-05 18:08 ` Bruce D'Arcus
2021-05-05 21:25   ` Bruce D'Arcus
2021-05-05 21:40     ` Bruce D'Arcus
2021-05-05 22:32     ` Bruce D'Arcus
2021-05-06  7:36     ` Denis Maier
2021-05-06 10:06       ` Bruce D'Arcus
2021-05-06 11:22         ` Bruce D'Arcus
2021-05-06 12:05     ` Nicolas Goaziou
2021-05-06 13:09       ` Bruce D'Arcus
2021-05-06 14:12         ` Nicolas Goaziou
2021-05-06 14:23           ` Bruce D'Arcus
2021-05-06 16:20             ` Nicolas Goaziou
2021-05-06 16:59               ` Bruce D'Arcus
2021-05-06  8:47 ` Bruce D'Arcus
2021-05-06 12:11   ` Nicolas Goaziou
2021-05-06 12:37     ` Bruce D'Arcus
2021-05-07 11:37       ` Bruce D'Arcus
2021-05-08 13:51         ` Bruce D'Arcus
2021-05-09  8:57           ` Nicolas Goaziou
2021-05-09 13:49             ` Bruce D'Arcus
2021-05-09 20:25               ` Nicolas Goaziou
2021-05-09 22:01                 ` Bruce D'Arcus
2021-05-10 17:07                   ` Bruce D'Arcus
2021-05-10 20:22                     ` Nicolas Goaziou
2021-05-10 20:52                       ` Bruce D'Arcus
2021-05-15 21:29                   ` Nicolas Goaziou
2021-05-15 21:54                     ` Bruce D'Arcus
2021-05-16  9:47                       ` Nicolas Goaziou
2021-05-11 12:13 ` Eric S Fraga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF-FPGPFQmuN3YNE08EtFFhV=ybZ101nkke-0SCBE1k2EbxfEA@mail.gmail.com' \
    --to=bdarcus@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: [wip-cite-new] New natbib processor' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).