From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id wBc1B9ZuOGKDkAAAgWs5BA (envelope-from ) for ; Mon, 21 Mar 2022 13:25:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id +LahBNZuOGLw+wAA9RJhRA (envelope-from ) for ; Mon, 21 Mar 2022 13:25:58 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id C7D1BC902 for ; Mon, 21 Mar 2022 13:25:56 +0100 (CET) Received: from localhost ([::1]:58890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWH6h-000256-FV for larch@yhetil.org; Mon, 21 Mar 2022 08:25:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWH0Y-0008NW-CR for emacs-orgmode@gnu.org; Mon, 21 Mar 2022 08:19:34 -0400 Received: from [2a00:1450:4864:20::62a] (port=39641 helo=mail-ej1-x62a.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nWH0T-00036b-A0 for emacs-orgmode@gnu.org; Mon, 21 Mar 2022 08:19:33 -0400 Received: by mail-ej1-x62a.google.com with SMTP id dr20so29074202ejc.6 for ; Mon, 21 Mar 2022 05:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andrew.cmu.edu; s=google-2021; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=52T53AJ7gPkLpkUxlm7qv1TdztL6x3yeCx3LtPbMswE=; b=dFq9VKLuxxtHNVpa80cBfb3nw/ffXoc617+QxAaRNoo1mD+RbP6W5Mw509kAi9XKaJ 79USgwguxp9X6crQtphd6Ocs73KQvNZ0wLjM/8zDkHhg6hXtKcPmaaAdaOnAtkS95QoW Zrf//9PJsQ/9EVDBieD/V7Bce4Dr6i4ilp9qiWe4CL9AoBWPGl6f4QS5kcVOgwDcuY2m U/dj+eSH7Vbvaq4n0PRWi+hs/b2Tvwq03199wlvwLGVurSIsD+ij7VXBPFMPM1+xCjxY PS8KJ1DcgiB3CKWnwmAxpzpSEc/XncCrx3O/HdPwCZe2uUkGfseWUVTNHO5I2Uo3xpo/ dFLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=52T53AJ7gPkLpkUxlm7qv1TdztL6x3yeCx3LtPbMswE=; b=26OSBHnz7sZY2LEwb2FL2LDsHYOPiuAV+YIijbsj9xnEoVm0EQCKng+uMs1dpT/jrK bttjh0ZYKqg84on/6moGaw0R1sKJyyXPrbRL4fk21CHdFDLq0Lplrq9iE6X+TPg0zKip onq+mgfKxYA3bRMbbm9iKzXqcaw3ldxlnOWurngKP8Xd1/AbvUl7kEykpNdMEKUu1w+J NFi2i9ItyxuL8uRmqdo+3dFskvkWpRCFxf3co5zpBibFFbf82yJ7grmIu5BFtvAIBDsW tbHSekdf2amsoaW/+siQmN276YQOEUosp93ZctC/iJ7zNNJvzVZ7r4c/E3LGfxLDkvEv 8ISA== X-Gm-Message-State: AOAM531bmAl05pHmZdULcL+iFQkVhVh5ScRPgK7G9HrrNHDdhhzLr2vC 5Zf5nYpUOmghE+k8ChPZibAhI9PMJvEsMHknxVQ= X-Google-Smtp-Source: ABdhPJyTBdg4IoG3qIZfo6EOpkaFDqBxY5C/CTkDF11/4ITmBfUAy8/f3CknDe1w/fmfH+Yaue9jZHvlBH20SGPdxxw= X-Received: by 2002:a17:907:7252:b0:6df:75cc:615e with SMTP id ds18-20020a170907725200b006df75cc615emr20813760ejc.683.1647865166551; Mon, 21 Mar 2022 05:19:26 -0700 (PDT) MIME-Version: 1.0 References: <87wngosqvm.fsf@nicolasgoaziou.fr> <87r16wukx0.fsf@gmail.com> In-Reply-To: <87r16wukx0.fsf@gmail.com> From: John Kitchin Date: Mon, 21 Mar 2022 08:19:15 -0400 Message-ID: Subject: Re: citations: org-cite vs org-ref 3.0 To: Timothy Content-Type: multipart/alternative; boundary="000000000000e3dfc105dab981a0" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::62a (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::62a; envelope-from=johnrkitchin@gmail.com; helo=mail-ej1-x62a.google.com X-Spam_score_int: 0 X-Spam_score: -0.1 X-Spam_bar: / X-Spam_report: (-0.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vikas Rawal , org-mode-email , Nicolas Goaziou Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1647865557; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=52T53AJ7gPkLpkUxlm7qv1TdztL6x3yeCx3LtPbMswE=; b=s84k99Y2GxZAKvVseUY6+DqbXkIb6fUYC79F1ego36VWfQzPC+Bp0xrLA+KDN5Zmt1SyG6 cmdn+d+6jW/zNEy2eQYGm6XrlEQeqHAlJfBDbSr2NX77uK3mZRIpZ7hw8Rca2GNtH21d1e D/Lrw1lfdIDjgM6WVZRM8wq6oXESYWpeWbygPSz48wr9OI34gTu/2+kZ/pwLMwnxM444Kg wDFvB6Ka11mIKZyxsArD2HtUpHbbqVEiTjm7mrgYKTVIqCf+OiOtzgXeyv8T5UZldC+J+7 Iy+X6t70sfjr+AEyhSbCq6tjPtMeS+LC8bu7mJioi/9j48zxgzjW3e3fj3eM5A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1647865557; a=rsa-sha256; cv=none; b=bYiNs0W8p5spPcoK8/nMvj84clFGuNi8hzhh2croEbUtOct/2m2V4Uxf9smssKndennRGv YKxt4gzIHI/mwtb4zQm1I3oWppZhEtmQzds2ef8zcaEqIoFj+aCCzJPMTUmH47kTcuxG1e Vl/fAQLEjMGqFgUSH6wm/u6k/rU4mfPOZSKhc28/Mhsw44Nps77TKx9ZTRaWQ6j1In8E4u EE9vXdjiC358oeKZAOcxH2up5Itg2gxSVqkbHkT4yY2k6cZQG7BYPixYgkvv02IpFCUQ0R hGXNi3viE3TxUm+cOvmdJonFzR6kDiYhzIA1d//ze4/5TaHPNEadsUFS/RiJHQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=andrew.cmu.edu header.s=google-2021 header.b=dFq9VKLu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=andrew.cmu.edu (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 5.28 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=andrew.cmu.edu header.s=google-2021 header.b=dFq9VKLu; dmarc=fail reason="SPF not aligned (relaxed)" header.from=andrew.cmu.edu (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: C7D1BC902 X-Spam-Score: 5.28 X-Migadu-Scanner: scn0.migadu.com X-TUID: QyPz5fCa8qze --000000000000e3dfc105dab981a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 20, 2022 at 9:57 PM Timothy wrote: > Hi John, > > Thanks for your considered response. > > When you contrast org-cite and org-ref, you say: > > > With org-ref, bib(la)tex export is almost fully supported, and is easy, > > I find this odd as org-cite supports bib(la)tex export, and rather easily= . > > =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 > =E2=94=82 #+bibliography: references.bib > =E2=94=82 #+cite_export: biblatex authortitle/authortitle-ibid > =E2=94=82 > =E2=94=82 [cite:@key] etc. > =E2=94=82 > =E2=94=82 #+print_bibliography: > =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 > > The limitation which I think is on your mind is that not all bib(la)tex > commands > are supported, and not in the =E2=80=9Cusual=E2=80=9D form. For instance,= to get > `pnotecite' one > would use `[cite/locators:]'. However, to get a 1-to-1 name mapping, you > can just > customise `org-cite-biblatex-styles'. For instance, `parencite' is not > currently > available, but if I just add `("parencite" nil "parencite" nil nil)' I ca= n > then do > `[cite/parencite:]' or if I replace the first `"parencite"' with > `"paren"', just > `[cite/paren:]'. > Yes, of course I mean the citation commands. > > A package could be created, say `org-cite-literal-biblatex' which is just > a copy > of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' a= nd > `org-cite-biblatex-style-shortcuts' (or just sets those variables in > `org-cite-biblatex'). As far as I can tell this would provide exactly the > functionality you say org-cite can=E2=80=99t provide but org-ref does. > I wrote this package you suggest in org-ref-cite. In discussions during that development, it was clear the preference was on the more abstracted, and uniform syntax across backends cite commands in org-cite, and not this kind of variant. Of course one can do this. It is not that org-cite can't provide it, it is that it doesn't at this time. Even so, it is only a partial solution to deprecating org-ref. > > You can already use `.bib' files, and so frankly I cannot myself see the > point in > org-ref=E2=80=99s existence beyond bifurcating the community on this. At = this > point the > only remaining motivation I see is old documents and current users, and > for this > a migration tool seems more appropriate. > I don=E2=80=99t mean to be overly critical, however this is my current ho= nest > assessment > of the situation. > > =E2=80=93 > All the best, > Timothy > > John Kitchin writes: > > > I do not think it is productive for the community to say or consider it > > is a sad situation. Many good things have emerged from these > > discussions, even if it is not yet consensus on a solution. It is a > > complex problem, with many years of effort by many people on each side. > > That is an indication of how ambitious this project is and that there > > may be more than one solution that is needed. It pains me quite a bit > > there is a sentiment of fractionation, and that I may be contributing t= o > > it. > > > > My regular job workload the past few years has been crushing, and I hav= e > > not had the time to participate in this that I wish I had. I am not sur= e > > I can add much here without sounding or feeling defensive about org-ref= , > > and my decision to continue supporting and developing it. I have though= t > > about this for most of the day, and in the (very long, apologies in > > advance) response that follows I will do my best to provide a balanced > > perspective (from my point of view) on the situation. > > > > Some specific context that is important to me is that I wrote org-ref > > long ago to solve a specific problem for me in the preparation of > > scientific publications that are destined for LaTeX export. I intended > > it to provide nearly equivalent bib(la)tex citation export, and as > > reasonable an export as possible for everything else. I use org-ref > > professionally, and it is a complete solution for me. I simply cannot > > compromise on the capability org-ref provides me, or wait for an > > alternative complete solution in org-mode. I have work I have to do now= , > > and org-ref lets me do it. This alone is reason enough for me to > > continue using, developing and supporting org-ref. I understand org is > > not intended to be a substitute for writing LaTeX, but it is a fact of > > my job that I have to do that. > > > > There are more than 8 years of legacy org-ref documents. I have written > > 40+ scientific papers with it, and countless technical documents with > > more than 8000 cite links among them. org-ref has exceeded 190K > > downloads from MELPA, so I feel obligated to maintain org-ref for > > myself, and those users. org-ref may be heavyweight in bundling a lot o= f > > capability together that could be separated into individual packages, > > but it is also convenient for people who need it, and a GitHUB issue or > > pull request away from new features. I remain committed to supporting > > this, and I do it in a way I can manage, hence the monolithic package > > design. > > > > org-cite was also developed to solve some specific citation problems fo= r > > others that org-ref did not address well at the time it was started. I > > believe those were issues like better pre/post note support, and > > integration with CSL. > > > > I think org-ref and org-cite have different priorities, they solve > > different problems with different approaches, and they have different > > pros and cons. I believe there are mutually incompatible compromises on= e > > must make here because the specific choices you make determine what is > > easy and what is possible. There is not a direct mapping of bib(la)tex > > and CSL as a citation processor. They are different programs and they > > don=E2=80=99t share citation commands, or style information. It is inev= itable > > that something will be lost in the translation between these from a > > single source like org, and whether that loss is acceptable depends on > > what you need. For many things, close enough is ok for me, but for > > manuscripts and proposals, they must be perfect, and in bib(la)tex form > > for the journals I publish in. It is not that one thing is possible in > > one and not the other; it is that you have to compromise one to do the > > other no matter what you choose and that typically makes one thing or > > the other easier to do. I am not even sure it is possible to do > > everything one can do in bib(la)tex with CSL, for example, I don=E2=80= =99t know > > the equivalent of in CSL. org-ref sides on making bib(la)tex > > easy, and CSL is possible. > > > > With org-cite, CSL can be readily used across export backends, more > > bibliography database formats are supported, and it is also possible to > > get LaTeX export, although there is no goal to fully support all of > > bib(la)tex. A pure org approach (e.g. org-files as bibliography > > database) can be used, there are a lot of CSL styles to work with, and > > you can develop or adapt your own style if needed. With reasonable > > defaults this should be a straightforward introduction to using > > citations for new users that works out of the box. I support that. > > > > With org-ref, bib(la)tex export is almost fully supported, and is easy, > > and other exports via CSL are possible. Of course, you must have a > > working LaTeX installation, only bibtex databases are supported, and > > working knowledge of bib(la)tex is required to leverage this. Whether > > you want it or not, you get a lot of extra utilities for getting bibtex > > entries from a DOI, and support for cross-references, indexes, > > glossaries and acronyms. This is a lot to ask of people who don=E2=80= =99t need > > it, and convenient for those who do. I support this. > > > > Which one of these approaches is right depends on what you want to be > > easy. Neither is right or wrong, that is determined by what you need at > > the time and what you prioritize in your solution. It is even possible > > you need both approaches at different times. The two approaches are not > > compatible, but it is org-mode after all, and you can certainly convert > > back and forth between them for the most part. > > > > Both projects have benefited from this discussion a lot. org has > > org-cite now, and org-ref now handles pre/post notes like org-cite does= , > > it supports CSL much better, and is even a little more modular, lighter > > weight, and more easily integrated with other completion backends than > > ivy or helm. That should broadly be viewed as a win-win situation. > > > > Here are some factors that have prevented me from deprecating org-ref. = I > > spent about a month and half trying to get a solution to this at > > , and I don=E2=80=99t make th= ese > > observations lightly. That solution was complete and highly functional > > for org-cite, but as I describe below not a replacement for org-ref at > > this time. I still welcome a new maintainer for this code. > > > > Cross-references are critical for me; without them, there is no path > > forward for me with org-cite. I did work on a cross-reference approach > > that leveraged org-cite syntax > > (), but there was > not > > much appetite for the approach so I abandoned that. There are > > cross-reference capabilities in org, that may be suitable for some > > applications, but they do not come close to what org-ref offers, and > > that the kind of technical documents I write require. For me, any > > cross-reference capability would also have to support what is possible > > in LaTeX, and preferrably look similar to the LaTeX commands. It has no= t > > been possible to write an orthogonal package that could co-exist with > > org-ref to address this; this would require a new syntax for > > cross-references in my opinion. My opinion is that practically citation= s > > and cross-references are just links to a place in your document (either > > a figure/table/section/etc, or an entry in a bibliography). In org-ref, > > both are represented by links; of course, they have different types and > > functions, but they both have follow like actions. My opinion seems to > > be in the minority on this. > > > > I do not like the abstraction away from LaTeX cite commands in org-cite= . > > This is an example of a compromise between LaTeX and CSL. They do not > > share common citation commands, so you can either choose one or the > > other, or make a new abstraction that generalizes them. I strongly favo= r > > the LaTeX commands because I write for LaTeX export, and there is > > extensive documentation for how to cite in LaTeX and what to expect. > > Clearly org-cite favors using the standardized abstractions in org-cite= , > > and then mapping them to the LaTeX commands I think. My perspective on > > this is partially one of an educator; I have taught a lot of people how > > to use org-mode for technical writing. This layer of abstraction adds > > additional complexity to documentation, and in teaching people what to > > do. As a LaTeX-centric user, that abstraction adds an additional > > cognitive load while writing I find unwelcome. I concede that it also > > reflects =E2=80=9Cwhat I do=E2=80=9D, that org is not LaTeX, and that o= thers may have a > > more CSL centric perspective. org-cite is for them. I can see that the > > abstraction away from the LaTeX cite commands strengthens the org is no= t > > LaTeX philosophy, and will serve part of the community well. If I wasn= =E2=80=99t > > required to generate LaTeX documents, and teach others how to do it, I > > would not feel so strongly. > > > > It is my opinion that the modularity of org-cite is a challenge. I thin= k > > it is too difficult to configure, and difficult to support, even more s= o > > than org-ref. I know my opinion differs from many on the list who want > > modularity and configurability. I have supported org-ref since around > > 2014, and even the modularity there (helm or ivy) has been a challenge > > to support. org-ref has always been configurable, but monolithic. Still= , > > I learned a lot from Bruce (thank you!) that pushed me to redesign part= s > > of org-ref to be more modular and more easily pluggable to other > > completion backends, and less specific on ivy/helm where practical. > > There are limitations to this I learned about, compromises one has to > > choose in doing it, and consequences in maintenance, support and > > documentation from them. We still don=E2=80=99t fully agree on some of = these > > points, but org-ref is closer to that ideal than it was. Maybe one day = I > > will abandon ivy like I did helm many years ago and feel differently > > about this, but that day is sufficiently far away that I don=E2=80=99t = see it > > now. > > > > Finally, the org-cite code is magnificent, and written at a level well > > above my coding skills. I am grateful to those who wrote it, and > > especially to Nicolas, for the opportunity to learn from it. The code I > > wrote in org-ref-cite was challenging. org-cite uses (IMO) advanced > > emacs-lisp techniques, and more complex data structures than I am > > accustomed to. I learned a lot studying the org-cite code, but I will b= e > > honest that I find it difficult to make contributions to. That gave me > > pause in continuing to develop it. It is fair to say that org-cite > > showed me some ways to address limitations of org-ref that I did not se= e > > before, org-ref is better for it, and the writing community that uses > > pre/post notes and biblatex is much better served as a result. > > > > Where does this leave me, org-ref and org-cite? I still have difference= s > > of opinion on design choices between them, and those differences are > > likely irreconcilable. These differences arise from my experiences in > > writing, teaching, using, developing and supporting org-ref. For those > > who need high fidelity LaTeX export like I do, I think org-ref is still > > a superior solution. For everyone else, and especially if you do not > > need sophisticated cross-references and don=E2=80=99t want the dependen= cies of > > org-ref, org-cite is likely the better solution. > > > > I am content to agree to disagree on these points and move forward with > > both packages because they solve different problems, are suitable for > > different communities, and they continue to benefit each other. I can > > see not everyone sees this as a positive situation though, and that has > > weighed heavily upon me lately. These times are heavy enough. Anyway, > > this turned out much longer than I expected, so thanks everyone who has > > contributed to making org better, I hope I got things mostly correct, > > you found it a fair assessment, we might still be friends, and thanks > > for reading to the end. > > > > j > --000000000000e3dfc105dab981a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 20, 2022 at 9:57 PM Tim= othy <tecosaur@gmail.com> w= rote:
Hi John,
Thanks for your considered response.

When you contrast org-cite and org-ref, you say:

> With org-ref, bib(la)tex export is almost fully supported, and is easy= ,

I find this odd as org-cite supports bib(la)tex export, and rather easily.<= br>
=E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80
=E2=94=82 #+bibliography: references.bib
=E2=94=82 #+cite_export: biblatex authortitle/authortitle-ibid
=E2=94=82
=E2=94=82 [cite:@key] etc.
=E2=94=82
=E2=94=82 #+print_bibliography:
=E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80

The limitation which I think is on your mind is that not all bib(la)tex com= mands
are supported, and not in the =E2=80=9Cusual=E2=80=9D form. For instance, t= o get `pnotecite' one
would use `[cite/locators:]'. However, to get a 1-to-1 name mapping, yo= u can just
customise `org-cite-biblatex-styles'. For instance, `parencite' is = not currently
available, but if I just add `("parencite" nil "parencite&qu= ot; nil nil)' I can then do
`[cite/parencite:]' or if I replace the first `"parencite"= 9; with `"paren"', just
`[cite/paren:]'.

Yes, of course I m= ean the citation commands.
=C2=A0

A package could be created, say `org-cite-literal-biblatex' which is ju= st a copy
of `oc-biblatex.el' with a different default `org-cite-biblatex-styles&= #39; and
`org-cite-biblatex-style-shortcuts' (or just sets those variables in `org-cite-biblatex'). As far as I can tell this would provide exactly t= he
functionality you say org-cite can=E2=80=99t provide but org-ref does.
<= /blockquote>

I wrote this package you suggest in org-ref= -cite. In discussions during that development, it was clear the preference = was on the more abstracted, and uniform syntax across backends cite command= s in org-cite, and not this kind of variant. Of course one can do this. It = is not that org-cite can't provide it, it is that it doesn't at thi= s time. Even so, it is only a partial solution to deprecating org-ref.
=C2=A0

You can already use `.bib' files, and so frankly I cannot myself see th= e point in
org-ref=E2=80=99s existence beyond bifurcating the community on this. At th= is point the
only remaining motivation I see is old documents and current users, and for= this
a migration tool seems more appropriate.=C2=A0

I don=E2=80=99t mean to be overly critical, however this is my current hone= st assessment
of the situation.

=E2=80=93
All the best,
Timothy

John Kitchin <jkitchin@andrew.cmu.edu> writes:

> I do not think it is productive for the community to say or consider i= t
> is a sad situation. Many good things have emerged from these
> discussions, even if it is not yet consensus on a solution. It is a > complex problem, with many years of effort by many people on each side= .
> That is an indication of how ambitious this project is and that there<= br> > may be more than one solution that is needed. It pains me quite a bit<= br> > there is a sentiment of fractionation, and that I may be contributing = to
> it.
>
> My regular job workload the past few years has been crushing, and I ha= ve
> not had the time to participate in this that I wish I had. I am not su= re
> I can add much here without sounding or feeling defensive about org-re= f,
> and my decision to continue supporting and developing it. I have thoug= ht
> about this for most of the day, and in the (very long, apologies in > advance) response that follows I will do my best to provide a balanced=
> perspective (from my point of view) on the situation.
>
> Some specific context that is important to me is that I wrote org-ref<= br> > long ago to solve a specific problem for me in the preparation of
> scientific publications that are destined for LaTeX export. I intended=
> it to provide nearly equivalent bib(la)tex citation export, and as
> reasonable an export as possible for everything else. I use org-ref > professionally, and it is a complete solution for me. I simply cannot<= br> > compromise on the capability org-ref provides me, or wait for an
> alternative complete solution in org-mode. I have work I have to do no= w,
> and org-ref lets me do it. This alone is reason enough for me to
> continue using, developing and supporting org-ref. I understand org is=
> not intended to be a substitute for writing LaTeX, but it is a fact of=
> my job that I have to do that.
>
> There are more than 8 years of legacy org-ref documents. I have writte= n
> 40+ scientific papers with it, and countless technical documents with<= br> > more than 8000 cite links among them. org-ref has exceeded 190K
> downloads from MELPA, so I feel obligated to maintain org-ref for
> myself, and those users. org-ref may be heavyweight in bundling a lot = of
> capability together that could be separated into individual packages,<= br> > but it is also convenient for people who need it, and a GitHUB issue o= r
> pull request away from new features. I remain committed to supporting<= br> > this, and I do it in a way I can manage, hence the monolithic package<= br> > design.
>
> org-cite was also developed to solve some specific citation problems f= or
> others that org-ref did not address well at the time it was started. I=
> believe those were issues like better pre/post note support, and
> integration with CSL.
>
> I think org-ref and org-cite have different priorities, they solve
> different problems with different approaches, and they have different<= br> > pros and cons. I believe there are mutually incompatible compromises o= ne
> must make here because the specific choices you make determine what is=
> easy and what is possible. There is not a direct mapping of bib(la)tex=
> and CSL as a citation processor. They are different programs and they<= br> > don=E2=80=99t share citation commands, or style information. It is ine= vitable
> that something will be lost in the translation between these from a > single source like org, and whether that loss is acceptable depends on=
> what you need. For many things, close enough is ok for me, but for
> manuscripts and proposals, they must be perfect, and in bib(la)tex for= m
> for the journals I publish in. It is not that one thing is possible in=
> one and not the other; it is that you have to compromise one to do the=
> other no matter what you choose and that typically makes one thing or<= br> > the other easier to do. I am not even sure it is possible to do
> everything one can do in bib(la)tex with CSL, for example, I don=E2=80= =99t know
> the equivalent of=C2=A0 in CSL. org-ref sides on making bib(la)tex
> easy, and CSL is possible.
>
> With org-cite, CSL can be readily used across export backends, more > bibliography database formats are supported, and it is also possible t= o
> get LaTeX export, although there is no goal to fully support all of > bib(la)tex. A pure org approach (e.g. org-files as bibliography
> database) can be used, there are a lot of CSL styles to work with, and=
> you can develop or adapt your own style if needed. With reasonable
> defaults this should be a straightforward introduction to using
> citations for new users that works out of the box. I support that.
>
> With org-ref, bib(la)tex export is almost fully supported, and is easy= ,
> and other exports via CSL are possible. Of course, you must have a
> working LaTeX installation, only bibtex databases are supported, and > working knowledge of bib(la)tex is required to leverage this. Whether<= br> > you want it or not, you get a lot of extra utilities for getting bibte= x
> entries from a DOI, and support for cross-references, indexes,
> glossaries and acronyms. This is a lot to ask of people who don=E2=80= =99t need
> it, and convenient for those who do. I support this.
>
> Which one of these approaches is right depends on what you want to be<= br> > easy. Neither is right or wrong, that is determined by what you need a= t
> the time and what you prioritize in your solution. It is even possible=
> you need both approaches at different times. The two approaches are no= t
> compatible, but it is org-mode after all, and you can certainly conver= t
> back and forth between them for the most part.
>
> Both projects have benefited from this discussion a lot. org has
> org-cite now, and org-ref now handles pre/post notes like org-cite doe= s,
> it supports CSL much better, and is even a little more modular, lighte= r
> weight, and more easily integrated with other completion backends than=
> ivy or helm. That should broadly be viewed as a win-win situation.
>
> Here are some factors that have prevented me from deprecating org-ref.= I
> spent about a month and half trying to get a solution to this at
> <https://github.com/jkitchin/org-ref-cite>, a= nd I don=E2=80=99t make these
> observations lightly. That solution was complete and highly functional=
> for org-cite, but as I describe below not a replacement for org-ref at=
> this time. I still welcome a new maintainer for this code.
>
> Cross-references are critical for me; without them, there is no path > forward for me with org-cite. I did work on a cross-reference approach=
> that leveraged org-cite syntax
> (<https://github.com/jkitchin/org-ref-cite= /issues/16>), but there was not
> much appetite for the approach so I abandoned that. There are
> cross-reference capabilities in org, that may be suitable for some
> applications, but they do not come close to what org-ref offers, and > that the kind of technical documents I write require. For me, any
> cross-reference capability would also have to support what is possible=
> in LaTeX, and preferrably look similar to the LaTeX commands. It has n= ot
> been possible to write an orthogonal package that could co-exist with<= br> > org-ref to address this; this would require a new syntax for
> cross-references in my opinion. My opinion is that practically citatio= ns
> and cross-references are just links to a place in your document (eithe= r
> a figure/table/section/etc, or an entry in a bibliography). In org-ref= ,
> both are represented by links; of course, they have different types an= d
> functions, but they both have follow like actions. My opinion seems to=
> be in the minority on this.
>
> I do not like the abstraction away from LaTeX cite commands in org-cit= e.
> This is an example of a compromise between LaTeX and CSL. They do not<= br> > share common citation commands, so you can either choose one or the > other, or make a new abstraction that generalizes them. I strongly fav= or
> the LaTeX commands because I write for LaTeX export, and there is
> extensive documentation for how to cite in LaTeX and what to expect. > Clearly org-cite favors using the standardized abstractions in org-cit= e,
> and then mapping them to the LaTeX commands I think. My perspective on=
> this is partially one of an educator; I have taught a lot of people ho= w
> to use org-mode for technical writing. This layer of abstraction adds<= br> > additional complexity to documentation, and in teaching people what to=
> do. As a LaTeX-centric user, that abstraction adds an additional
> cognitive load while writing I find unwelcome. I concede that it also<= br> > reflects =E2=80=9Cwhat I do=E2=80=9D, that org is not LaTeX, and that = others may have a
> more CSL centric perspective. org-cite is for them. I can see that the=
> abstraction away from the LaTeX cite commands strengthens the org is n= ot
> LaTeX philosophy, and will serve part of the community well. If I wasn= =E2=80=99t
> required to generate LaTeX documents, and teach others how to do it, I=
> would not feel so strongly.
>
> It is my opinion that the modularity of org-cite is a challenge. I thi= nk
> it is too difficult to configure, and difficult to support, even more = so
> than org-ref. I know my opinion differs from many on the list who want=
> modularity and configurability. I have supported org-ref since around<= br> > 2014, and even the modularity there (helm or ivy) has been a challenge=
> to support. org-ref has always been configurable, but monolithic. Stil= l,
> I learned a lot from Bruce (thank you!) that pushed me to redesign par= ts
> of org-ref to be more modular and more easily pluggable to other
> completion backends, and less specific on ivy/helm where practical. > There are limitations to this I learned about, compromises one has to<= br> > choose in doing it, and consequences in maintenance, support and
> documentation from them. We still don=E2=80=99t fully agree on some of= these
> points, but org-ref is closer to that ideal than it was. Maybe one day= I
> will abandon ivy like I did helm many years ago and feel differently > about this, but that day is sufficiently far away that I don=E2=80=99t= see it
> now.
>
> Finally, the org-cite code is magnificent, and written at a level well=
> above my coding skills. I am grateful to those who wrote it, and
> especially to Nicolas, for the opportunity to learn from it. The code = I
> wrote in org-ref-cite was challenging. org-cite uses (IMO) advanced > emacs-lisp techniques, and more complex data structures than I am
> accustomed to. I learned a lot studying the org-cite code, but I will = be
> honest that I find it difficult to make contributions to. That gave me=
> pause in continuing to develop it. It is fair to say that org-cite
> showed me some ways to address limitations of org-ref that I did not s= ee
> before, org-ref is better for it, and the writing community that uses<= br> > pre/post notes and biblatex is much better served as a result.
>
> Where does this leave me, org-ref and org-cite? I still have differenc= es
> of opinion on design choices between them, and those differences are > likely irreconcilable. These differences arise from my experiences in<= br> > writing, teaching, using, developing and supporting org-ref. For those=
> who need high fidelity LaTeX export like I do, I think org-ref is stil= l
> a superior solution. For everyone else, and especially if you do not > need sophisticated cross-references and don=E2=80=99t want the depende= ncies of
> org-ref, org-cite is likely the better solution.
>
> I am content to agree to disagree on these points and move forward wit= h
> both packages because they solve different problems, are suitable for<= br> > different communities, and they continue to benefit each other. I can<= br> > see not everyone sees this as a positive situation though, and that ha= s
> weighed heavily upon me lately. These times are heavy enough. Anyway,<= br> > this turned out much longer than I expected, so thanks everyone who ha= s
> contributed to making org better, I hope I got things mostly correct,<= br> > you found it a fair assessment, we might still be friends, and thanks<= br> > for reading to the end.
>
> j
--000000000000e3dfc105dab981a0--