"Bruce D'Arcus" <bdar...@gmail.com> writes:
> On Tue, May 4, 2021 at 11:46 AM Eric S Fraga <e.fr...@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
