Re: Notes about citations in Org (part 3)

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

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

> On Tue, May 4, 2021 at 11:46 AM Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>
>> I wonder whether it might be good to have a default LaTeX column as
>> well, i.e. not natbib, a column that represents what LaTeX supports out
>> of the box which is only the \cite{key} command.
>
> Makes sense to me.
>
> I guess the question at this stage is how to iterate this.
>
> I already added a change or two based on feedback from Joost, and it
> does make sense to add a new column for latex.
>
> It seems easier to me to do it on the wiki, rather than post a new
> version to the list every time, in part because it allows others to
> edit it.
>
> Any thoughts Nicolas?

Is the default \cite{key} command (without any other package) used? I'm
not sure we should provide it since we are working towards more complete
solutions.

I'd like to give a shot at "oc-natbib.el" in a few hours. It may give an
incentive to start out "oc-biblatex.el" (which is a bit harder).

AFAIU, the idea is to use styles from you wiki. However, sub-styles are
not mentioned. They could be "full" for the starred variants, "caps" for
the capitalized ones, and "alt" for those without parenthesis, so one
could write:

  [cite/text/alt/full/caps:...]  (in any order)

and obtain

  \Citealt*{...}

I hope we can find a shortcut, but it doesn't matter for now.

About sub-styles. The style is parsed as a string, so in the example
above, (org-element-property :style citation-object) returns
"text/alt/full/caps". 

Supporting sub-styles could be as simple as providing a function that
returns a non-nil value if a given sub-style belongs to the style. e.g.,

  (org-cite-has-substyle-p style "full") => t

  (org-cite-has-substyle-p style "author") => nil

I.e, sub-styles are not formally supported in the parser, but tooling
can take them into account.

Of course, we can also support them fully, i.e.
(org-element-property :style citation-object) returns a list of strings.
It depends how simple the common single style case should be.

To limit verbosity, we may want to stay (it's not mandatory) at one
sub-level instead, and use single characters for processor specific
variants, e.g.,

  [cite//aC*:...]  <-- default style with alt+full+caps

If style are in common use, processors might as well declare them in
`org-cite-register-processor' as a help for, e.g., functions inserting
citations. Hmm.

WDYT?

Regards,
-- 
Nicolas Goaziou