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,