From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id APb6DjUVRGINcwEAgWs5BA (envelope-from ) for ; Wed, 30 Mar 2022 10:30:45 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id mGQuDDUVRGKJPQEA9RJhRA (envelope-from ) for ; Wed, 30 Mar 2022 10:30:45 +0200 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 68DFD282C0 for ; Wed, 30 Mar 2022 10:30:44 +0200 (CEST) Received: from localhost ([::1]:39540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nZTj1-00055u-2T for larch@yhetil.org; Wed, 30 Mar 2022 04:30:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43546) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nZTbA-00085b-Hm for emacs-orgmode@gnu.org; Wed, 30 Mar 2022 04:22:37 -0400 Received: from [2a00:1450:4864:20::336] (port=44848 helo=mail-wm1-x336.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nZTb5-0003s9-I1 for emacs-orgmode@gnu.org; Wed, 30 Mar 2022 04:22:34 -0400 Received: by mail-wm1-x336.google.com with SMTP id bg31-20020a05600c3c9f00b00381590dbb33so2942146wmb.3 for ; Wed, 30 Mar 2022 01:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=ppv1jzctQ/WyT8mPHlq/CQotisKDVM73DYJIYwei5lA=; b=V6Q7fBkPo3kaDnonKesGR3jynzt4pA28ZqAm3wA3UMzqb11ckYbes5A+jjKL0qs3Vh wZ47EQVAtDeRQUDP5Ne9FZEa7LRa1tOSWvD2LppF13rAwTHnmdzHQtGtgts54UYtuZAM 2AgGrSD2aVcp3OEJ8D8V4/RCoP81NY93przd/FS5m9rO82YaGpQryqWshpP1FI1qmWkP dZPCzDyKSeKqjnYzsaI2cWmH4eI/ridWOpKBjgYnlyuQXamhZi2z/eQ6TkyPYRycmUra SRsNIr7H9f3ND/W+EFXQI3fQJl1s48F8qL2dwUdHp4LmVMVj7cWCwOWF/0o7Eyh8oTs+ yt5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=ppv1jzctQ/WyT8mPHlq/CQotisKDVM73DYJIYwei5lA=; b=EbmBuz6/nNJBWuSVkQaxBgTehLvbrgazL4Asq4IJCHdFdmnFOE4Kk9IOvACsYrfatw ycXmNHigT8BL0TVwR/0Z2JsXzZYdXKC3dFLU+OeoDJyIDeJ7nXfadu2DI6PgeYKE6XXA aYhxm7CFreFnvN5pdSWxKOt7t815zQI4ssRLbtQRrhI0nOq7lRqhUeOaC012BusgavBj 9+L//VVoPD9S4Fh6Pu1HpAMgSyMaQFU/5/Opo/4zHIXyJeyJhc4ka4dzyRvBqhUIpkoV a4bhzotsmhH4VjUxx44bLsx3hglsSCbzpme7XzE5qtW3DHomFu9AalhI1S0SVrGj9037 Dvtw== X-Gm-Message-State: AOAM533kyjhS1msIOaf/bD24D2Mdpmt8ZmlPvGOF9rqFy7S6mmKfiOB5 Mfd4OpIk5F8BT3EmgfzV+2FC9glHS7g= X-Google-Smtp-Source: ABdhPJwl3fvm/PNhYlYbr9yJeqelLKy1dFYVKvQrElVJcz7BKKOm+EtVtWQ3Fe+e89lLFb9U/ii3bg== X-Received: by 2002:a05:600c:3789:b0:38c:bd93:77d6 with SMTP id o9-20020a05600c378900b0038cbd9377d6mr3397508wmr.12.1648628544700; Wed, 30 Mar 2022 01:22:24 -0700 (PDT) Received: from [192.168.1.111] (18.red-81-42-219.staticip.rima-tde.net. [81.42.219.18]) by smtp.gmail.com with ESMTPSA id v4-20020adfa1c4000000b00205c6dfc41esm8933165wrv.18.2022.03.30.01.22.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Mar 2022 01:22:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------g3mHqJMDV0QntlTYEnRaO9om" Message-ID: Date: Wed, 30 Mar 2022 10:23:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Emacs-orgmode Digest, Vol 193, Issue 30 Content-Language: en-GB To: emacs-orgmode@gnu.org References: From: Ypo In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::336 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=ypuntot@gmail.com; helo=mail-wm1-x336.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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: , 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=1648629044; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=ppv1jzctQ/WyT8mPHlq/CQotisKDVM73DYJIYwei5lA=; b=i1jf/m5GOWyqre3KI9xq8l9J3H93HmcSPfKQ41NUxxX5No7ZHrCCHDbYP+DZTVzV90+HvQ PCCSFeVdZXqCbjVRJE0V4oIdaXkWAfgfl0c6G0dvlmXzUi/SYWcUuHXsIxEJNFx5mNUBHW K3VdI2fGfgpPOcyak9Fp+rYkZdo8PcYCbhLrEJNFe9Hpn//qaxAOXnHu1nXNJa0xa+oSLl skiPt5NuZdGXWJ/Hc6dfBkXL6aviKC4F8yLy/Zb+Qp0qB8KZ/bSjtpr1HyQb6z8DdpcOXn XOjVvKOqYBx8KpubgrsL2qqY2YrkgxLIVtZHosJI9YDpIHAkDyJp8CxNWlSz0w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648629044; a=rsa-sha256; cv=none; b=FcYd2UX9d4A2YCBK0hUh2VuB0cdqZgspYk8EJPlk6QarknUYYbcxi+dLFMhC4uJO9h9avW dhNvf7CdvXgTXqQyi+ld1Mfb8bpTPy3SH6sBserMlCkIAGtL8fYMKs6thP/VHc/6Auatx3 VTu7vhXlK5eH97gh2LaLbf0ig8DP6Z0MkYY6a+huJXG76feZSgko7PqDXRVjB2mcE4SQC5 wVIm4KKilerPfzjCVoNv9aUy6bzCTekNnuZmyGSDc9hv0Qew1yRM+pY1aPYg2V5a5H7PkZ 3Gvv9VQ6zB5uK9b2sw0ptUKJDILKp6gubB/p1d2ldeF1nlCYK/zbvtCCmbPGFA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=V6Q7fBkP; dmarc=pass (policy=none) header.from=gmail.com; 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: -6.37 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=V6Q7fBkP; dmarc=pass (policy=none) header.from=gmail.com; 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: 68DFD282C0 X-Spam-Score: -6.37 X-Migadu-Scanner: scn0.migadu.com X-TUID: q0mq9TDWbNyw This is a multi-part message in MIME format. --------------g3mHqJMDV0QntlTYEnRaO9om Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks, Detlef, I re-installed this essential package for me. El 28/03/2022 a las 18:00, emacs-orgmode-request@gnu.org escribió: > Send Emacs-orgmode mailing list submissions to > emacs-orgmode@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/emacs-orgmode > or, via email, send a message with subject or body 'help' to > emacs-orgmode-request@gnu.org > > You can reach the person managing the list at > emacs-orgmode-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emacs-orgmode digest..." > > > Today's Topics: > > 1. Re: citations: org-cite vs org-ref 3.0 (John Kitchin) > 2. Re: citations: org-cite vs org-ref 3.0 (John Kitchin) > 3. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus) > 4. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus) > 5. Re: Is there a maintained calf-calendar fork? (Detlef Steuer) > 6. Re: [PATCH] Fix typo in org-todo-list doc string (Bastien) > 7. Re: Bug: Incorrect weekday in The Org Manual [9.3 > (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] (Bastien) > 8. Re: citations: org-cite vs org-ref 3.0 (Max Nikulin) > 9. Re: Faulty SVG width in default HTML export style (Bastien) > 10. Re: Custom TODO states for one item (Bastien) > 11. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus) > 12. ox-latex table tabbing support. (emacs@vergauwen.me) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 27 Mar 2022 13:00:40 -0400 > From: John Kitchin > To: Nicolas Goaziou > Cc: Vikas Rawal,emacs-orgmode@gnu.org > Subject: Re: citations: org-cite vs org-ref 3.0 > Message-ID: > Content-Type: text/plain; charset=utf-8 > > > Nicolas Goaziou writes: > >> Hello, >> >> 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. >> [...] >> >>> 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 of >>> 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. >> I think there's a misunderstanding here. Org Cite was never meant as >> a replacement for Org Ref. It was designed from the beginning as >> a framework other libraries could rely on and extend in their own way. >> Org Ref could have been one of them. >> >> It looks like a social problem to me. I remember well asking for >> feedback when implementing the various prototypes, i.e., ways to make >> Org Cite more useful to other libraries. I don't think I got much of it, >> barring the cross-references topic, which is not solved. Maybe I was not >> explicit enough about what I was expecting. For example, this is—please >> correct me if I'm wrong—the first time I read about the "BibLaTeX is not >> fully implemented in Org Cite" and "Org Cite is adding an extra >> abstraction layer on top of BibLaTeX commands" issues, which are both >> trivial to solve, either on the Org Cite or the Org Ref side. But then >> again, it is perfectly fine if Org Cite doesn't provide that, as some >> libraries can extend it if needed. > I don't think it is the first time I have mentioned biblatex is not > fully implemented, but I am not sure. I have mentioned things like > \citenum somewhere, but it is not the main point. > > I know it is not that difficult to add support for LaTeX export in > org-cite, e.g. [cite/num:]. I don't think it is all that easy to add > additional backend support though, for something like [cite/num:] in > HTML or other backends. No doubt, it is not impossible, if someone would > just do it, and that might include extending citeproc too, or developing > some pre-processing function to get a citation number, or something > else. Whether cite/num or any other command exists is not the main > point. What is the point is what mechanisms exist to support the > addition, and the exports to various backends. > > Regarding that org-cite adds an abstraction layer, how else could one > interpret this (from > https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax) > other than abstraction: > > [cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}? > > Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even, > \citenum? > > I get it, you can define [cite/noauthor/year:] or even [cite/year:] or > [cite/y:] and even [cite/citeyear:] to get the command in there, and > something for each of those other ones. Maybe even the documented > convention will change to some other potentially mnemonic form. > > I also get they are not all that common perhaps, except for a few people > who use them, and maybe should be responsible for supporting it > themselves, either by defcustom or their own library. > > This is just trading a proliferation of links for a proliferation of > styles IMO, and it feels a lot like the XKCD standards issue > https://xkcd.com/927/. > > As others have argued, it is just a bit of knowledge, maybe a UI can > compensate to help you insert what you want, then know what it means > later. It is my opinion that this will be a technical debt though. I am > content to agree to disagree on this point. > > It might be a social problem, and I do not think it is trivial to solve. > It is not just about having a syntax that works. I wrote and shared a > whole set of processors for org-cite that did or tried to do all those > things above. It was fine to use, but it was very difficult code to > write for me. I don't personally want to support it in part because it > was so difficult to write. I don't even want to support it for my own > use at this time. This should not stop anyone who wants to do that > themselves though. Maybe there is a cleaner approach I missed, or others > may be better programmers, and/or have more time to figure this out. At > this time, I do not have time to make for it. > >> On the other hand, there have been much activity on GitHub repositories, >> i.e., out of this mailing list. It seems to me Org Ref project has been >> trying to work around possible blockers in Org Cite project the whole >> time without the latter knowing about them, and having an opportunity to >> lift them. > There is nothing nefarious happening here. That work happened in public, > and with some interactions with people on the org-list including Bruce. > > Some motivation for org-cite stemmed from at least perceived limitations > in org-ref, especially related to pre/post notes and CSL support. I > think it is totally reasonable to learn if those were real limitations > or not. > >>> 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. >> But it is not. There are now two, more or less official, citations >> syntax. Interoperability is the big loss. Features do not count; it is >> perfectly fine to have different packages targeting different needs, as >> long as they share the same syntax. >> >> Hopefully, at some point, we'll be able to build a list of blockers that >> prevent Org Ref being built on top of Org Cite, and proceed. > You can use the org-cite syntax with org-ref. If all one wants is a > citation syntax for their org-files, and an occasional standard > (cite/citet/citep) LaTeX export export, org-cite will probably meet their > needs. As a few have reported, it works for them. > > If you have very large bibtex files, you may find that the basic > processors don't have good performance yet, and you may need to > configure org to use a performant set of processors for activation and > insertion. Yes, this is being worked on in org, and you will need to use > the latest version of org to benefit from it. > > If you have very specific needs in biblatex, you may find not every > command has a corresponding org-cite implementation. You may have to add > this to your own setup, or use a specific set of processors that provide > it. You can do that, and still use it with org-ref. > > Maybe one day I will have time to try integrating org-cite with org-ref > again. I have been stretched too thin by work for the past two years, > and in the forseeable future to spend much time on org-cite. This is a > me issue, not an org-cite issue. > > > > > >> Regards, > --------------g3mHqJMDV0QntlTYEnRaO9om Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Thanks, Detlef, I re-installed this essential package for me.



El 28/03/2022 a las 18:00, emacs-orgmode-request@gnu.org escribió:
Send Emacs-orgmode mailing list submissions to
	emacs-orgmode@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.gnu.org/mailman/listinfo/emacs-orgmode
or, via email, send a message with subject or body 'help' to
	emacs-orgmode-request@gnu.org

You can reach the person managing the list at
	emacs-orgmode-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emacs-orgmode digest..."


Today's Topics:

   1. Re: citations: org-cite vs org-ref 3.0 (John Kitchin)
   2. Re: citations: org-cite vs org-ref 3.0 (John Kitchin)
   3. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus)
   4. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus)
   5. Re: Is there a maintained calf-calendar fork? (Detlef Steuer)
   6. Re: [PATCH] Fix typo in org-todo-list doc string (Bastien)
   7. Re: Bug: Incorrect weekday in The Org Manual [9.3
      (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)] (Bastien)
   8. Re: citations: org-cite vs org-ref 3.0 (Max Nikulin)
   9. Re: Faulty SVG width in default HTML export style (Bastien)
  10. Re: Custom TODO states for one item (Bastien)
  11. Re: citations: org-cite vs org-ref 3.0 (Bruce D'Arcus)
  12. ox-latex table tabbing support. (emacs@vergauwen.me)


----------------------------------------------------------------------

Message: 1
Date: Sun, 27 Mar 2022 13:00:40 -0400
From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Vikas Rawal <vikasrawal@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: citations: org-cite vs org-ref 3.0
Message-ID: <m24k3jnq0k.fsf@andrew.cmu.edu>
Content-Type: text/plain; charset=utf-8


Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:


Hello,

John Kitchin <jkitchin@andrew.cmu.edu> 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.

[...]


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 of
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.

I think there's a misunderstanding here. Org Cite was never meant as
a replacement for Org Ref. It was designed from the beginning as
a framework other libraries could rely on and extend in their own way.
Org Ref could have been one of them.

It looks like a social problem to me. I remember well asking for
feedback when implementing the various prototypes, i.e., ways to make
Org Cite more useful to other libraries. I don't think I got much of it,
barring the cross-references topic, which is not solved. Maybe I was not
explicit enough about what I was expecting. For example, this is—please
correct me if I'm wrong—the first time I read about the "BibLaTeX is not
fully implemented in Org Cite" and "Org Cite is adding an extra
abstraction layer on top of BibLaTeX commands" issues, which are both
trivial to solve, either on the Org Cite or the Org Ref side. But then
again, it is perfectly fine if Org Cite doesn't provide that, as some
libraries can extend it if needed.

I don't think it is the first time I have mentioned biblatex is not
fully implemented, but I am not sure. I have mentioned things like
\citenum somewhere, but it is not the main point.

I know it is not that difficult to add support for LaTeX export in
org-cite, e.g. [cite/num:]. I don't think it is all that easy to add
additional backend support though, for something like [cite/num:] in
HTML or other backends. No doubt, it is not impossible, if someone would
just do it, and that might include extending citeproc too, or developing
some pre-processing function to get a citation number, or something
else. Whether cite/num or any other command exists is not the main
point. What is the point is what mechanisms exist to support the
addition, and the exports to various backends.

Regarding that org-cite adds an abstraction layer, how else could one
interpret this (from
https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax)
other than abstraction:

[cite/na/b:@key] or [cite/noauthor/bare:@key] to mean \citeyear{key}?

Why wouldn't it be \citetitle? or \citeurl, or \citedate? or even,
\citenum?

I get it, you can define [cite/noauthor/year:] or even [cite/year:] or
[cite/y:] and even [cite/citeyear:] to get the command in there, and
something for each of those other ones. Maybe even the documented
convention will change to some other potentially mnemonic form. 

I also get they are not all that common perhaps, except for a few people
who use them, and maybe should be responsible for supporting it
themselves, either by defcustom or their own library.

This is just trading a proliferation of links for a proliferation of
styles IMO, and it feels a lot like the XKCD standards issue
https://xkcd.com/927/.

As others have argued, it is just a bit of knowledge, maybe a UI can
compensate to help you insert what you want, then know what it means
later. It is my opinion that this will be a technical debt though. I am
content to agree to disagree on this point.

It might be a social problem, and I do not think it is trivial to solve.
It is not just about having a syntax that works. I wrote and shared a
whole set of processors for org-cite that did or tried to do all those
things above. It was fine to use, but it was very difficult code to
write for me. I don't personally want to support it in part because it
was so difficult to write. I don't even want to support it for my own
use at this time. This should not stop anyone who wants to do that
themselves though. Maybe there is a cleaner approach I missed, or others
may be better programmers, and/or have more time to figure this out. At
this time, I do not have time to make for it.


On the other hand, there have been much activity on GitHub repositories,
i.e., out of this mailing list. It seems to me Org Ref project has been
trying to work around possible blockers in Org Cite project the whole
time without the latter knowing about them, and having an opportunity to
lift them.

There is nothing nefarious happening here. That work happened in public,
and with some interactions with people on the org-list including Bruce. 

Some motivation for org-cite stemmed from at least perceived limitations
in org-ref, especially related to pre/post notes and CSL support. I
think it is totally reasonable to learn if those were real limitations
or not. 


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.

But it is not. There are now two, more or less official, citations
syntax. Interoperability is the big loss. Features do not count; it is
perfectly fine to have different packages targeting different needs, as
long as they share the same syntax.

Hopefully, at some point, we'll be able to build a list of blockers that
prevent Org Ref being built on top of Org Cite, and proceed.

You can use the org-cite syntax with org-ref. If all one wants is a
citation syntax for their org-files, and an occasional standard
(cite/citet/citep) LaTeX export export, org-cite will probably meet their
needs. As a few have reported, it works for them.

If you have very large bibtex files, you may find that the basic
processors don't have good performance yet, and you may need to
configure org to use a performant set of processors for activation and
insertion. Yes, this is being worked on in org, and you will need to use
the latest version of org to benefit from it.

If you have very specific needs in biblatex, you may find not every
command has a corresponding org-cite implementation. You may have to add
this to your own setup, or use a specific set of processors that provide
it. You can do that, and still use it with org-ref.

Maybe one day I will have time to try integrating org-cite with org-ref
again. I have been stretched too thin by work for the past two years,
and in the forseeable future to spend much time on org-cite. This is a
me issue, not an org-cite issue.






Regards,
--------------g3mHqJMDV0QntlTYEnRaO9om--