On Sun, Mar 20, 2022 at 8:09 AM Vikas Rawal <vikasra...@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
