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

[Nicolas Goaziou]

Hello,

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

> To bottom line it, seems the decision comes down to something like
> these three choices:
>
> 1. no change; keep sub-styles as they are ATM
> 2. change sub-styles to a simple string. So [cite/text/caps+full:...],
> where sub-style is the string "caps+full"; short cut would be
> something like [cite:/t/c+f:...]
> 2. remove sub-styles entirely; just have things like
> [cite/text+caps-full:...], where the style is "text+caps-full"; or
> with shortcuts [cite/t+c-f:...]
>
> Any of them seem reasonable to me.
>
> Maybe 2 is the best balance of flexibility and simplicity?

But there are two 2 ;)

I think that sub-styles as currently implemented, i.e., per processor,
are not useful. They could as well be replaced by a list of regular
styles (e.g., "text-caps-full").

Completion is not really an issue either. We could require
export-oriented citation processors to declare the styles they support
through a dedicated keyword in `org-cite-register-processor'.
Completions utilities, like the function you wrote, could then read from
that list.

The question you raise about compatibility between processors is
interesting however. Without sub-styles, non-standard styles (roughly
anything but default, text, author and year) would, as you noted,
fallback to default style upon switching citation processors. E.g.,
"text-caps-full" would become default. With sub-styles, OTOH, fallback
mechanism would be able to grab root style and try using it before
dropping the ball to default. E.g., "text/caps-full" could gracefully
degrade to "text", and, if not supported, default.

Sub-styles buy us nicer switching between processors, indeed. But they
come at a price, too. In particular, we need to re-define inheritance
between styles defined in `org-cite-export-processor', "cite_export"
keyword and the citation object. As I wrote earlier in this thread,
there are multiple ways to deal with it, so a clear design is in order.

Plain styles already exist. Sub-styles requires more work. Does the
benefit outweigh it? If so, what do you suggest for the inheritance
problem?

Regards,
-- 
Nicolas Goaziou