Re: citations: org-cite vs org-ref 3.0

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 8:09 AM Vikas Rawal <vikasrawal@gmail.com> wrote:

> What is the general view of the community about this? Is there a 
> comprehensive discussion of pros and cons of each?

Not really, but there's John's summary here:

https://github.com/jkitchin/org-ref#what-about-org-cite

The high-level discussion at the beginning, including the enumerated
points, seems right to me.

The following point that "org-cite does not meet my citation and
technical document publishing needs, and it was not possible to
integrate it into org-ref without compromising those" is more subject
to debate, particularly the first clause.

I don't see any practical advantage to the org-ref syntax and model,
unless you include cross-references and such.

But that's because I just don't think cross-references and indexes
should be handled in org-cite; I think if we need improvements in
existing cross-references etc support, we should add those there.

I suspect he's also meaning the different ways that citation
commands/styles are handled in the two systems.

Here's an example from org-ref 3:

[[citealp:See &kitchin-2015-examp page 2]]

Note that first piece: "citealp". That's the command, which org-ref
will output directly to LaTeX/Natbib as \citealp. Note that command
only makes sense for natbib.

Org-cite has a different abstraction here: the style/substyle system.
So the above would be ...

[cite/bare:See @kitchin-2015-examp page 2]

... and then whatever export processor would map that "bare" style to
the appropriate output.

So that leaves the last bit; the "not possible" point, which I can't
address. It would obviously be nice if org-ref supported org-cite in
the future.

> What is everyone doing? I was an org-ref user for long before I switched to 
> org-cite. I can now shift to citar but since I am an ivy user, the switch is 
> not trivial. Also, I like many helper functions that John has created, and 
> would have to miss those if I do not use org-ref/org-ref-cite.

A month or so ago, John offered to turn over maintenance of
org-ref-cite to someone else, which might be one good option for
someone who uses ivy, in particular, and interested in developing it
further.

More generally, the modular design of org-cite should result, in time,
with diverse components, including for different completion
frameworks. For example, I think it'd be pretty easy to create an
insert process for helm-bibtex or ivy-bibtex, and a follow processor
for bibtex-completion.

Or alternatively, as citar now no longer requires bibtex-completion,
someone could write a small citar front-end for ivy as an insert
processor.

The whole point of the org-ctite design is it should be easy for users
to mix-and-match different pieces, and for documents to remain
compatible across users and export backends. It also allows developers
to focus on those small components.

Bruce