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
Date: Sun, 27 Mar 2022 13:00:40 -0400 [thread overview]
Message-ID: <m24k3jnq0k.fsf@andrew.cmu.edu> (raw)
In-Reply-To: <87k0ckjs4o.fsf@nicolasgoaziou.fr>
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,
--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
Pronouns: he/him/his
next prev parent reply other threads:[~2022-03-27 19:41 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-20 12:08 citations: org-cite vs org-ref 3.0 Vikas Rawal
2022-03-20 13:19 ` Nicolas Goaziou
2022-03-20 14:08 ` Vikas Rawal
2022-03-20 14:38 ` Bruce D'Arcus
2022-03-21 0:31 ` John Kitchin
2022-03-21 1:39 ` Timothy
2022-03-21 8:16 ` Dominik Schrempf
2022-03-21 11:51 ` Bruce D'Arcus
2022-03-21 12:34 ` Dominik Schrempf
2022-03-21 12:52 ` Bruce D'Arcus
2022-03-21 13:05 ` Dominik Schrempf
2022-03-21 13:24 ` Bruce D'Arcus
2022-03-23 21:27 ` Nicolas Goaziou
2022-03-23 21:53 ` Bruce D'Arcus
2022-03-23 22:04 ` Nicolas Goaziou
2022-03-23 22:47 ` Bruce D'Arcus
2022-03-24 10:04 ` Dominik Schrempf
2022-03-21 12:19 ` John Kitchin
2022-03-21 12:42 ` Bruce D'Arcus
2022-03-21 14:06 ` John Kitchin
2022-04-19 22:37 ` Bruce D'Arcus
2022-03-21 3:27 ` Vikas Rawal
2022-03-21 11:51 ` John Kitchin
2022-03-21 17:20 ` Vikas Rawal
2022-03-25 15:53 ` Max Nikulin
2022-03-27 15:33 ` John Kitchin
2022-03-27 15:44 ` Vikas Rawal
2022-03-25 17:10 ` Max Nikulin
2022-03-26 12:41 ` Bruce D'Arcus
2022-03-27 19:40 ` John Kitchin
2022-03-28 12:34 ` Max Nikulin
2022-03-28 13:16 ` Bruce D'Arcus
2022-03-29 15:22 ` Max Nikulin
2022-03-29 16:14 ` Bruce D'Arcus
2022-03-30 13:50 ` Denis Maier
2022-03-31 15:10 ` Max Nikulin
2022-03-31 17:27 ` Bruce D'Arcus
2022-04-02 11:41 ` org-cite, CSL styles and space before citation Max Nikulin
2022-03-30 21:43 ` citations: org-cite vs org-ref 3.0 John Kitchin
2022-03-21 12:59 ` juh
2022-03-22 13:03 ` indieterminacy
2022-03-23 21:06 ` Nicolas Goaziou
2022-03-27 17:00 ` John Kitchin [this message]
2022-03-27 23:17 ` Bruce D'Arcus
2022-03-21 14:40 ` Max Nikulin
2022-03-21 15:19 ` Bruce D'Arcus
2022-03-21 17:00 ` John Kitchin
2022-03-25 15:21 ` Max Nikulin
2022-03-22 14:41 ` Max Nikulin
2022-03-22 17:20 ` Bruce D'Arcus
2022-03-23 12:44 ` Max Nikulin
2022-03-23 14:39 ` Bruce D'Arcus
2022-03-23 15:26 ` Eric S Fraga
2022-03-23 17:17 ` Max Nikulin
2022-03-23 22:50 ` Bruce D'Arcus
2022-03-26 19:08 ` M. Pger
2022-03-22 23:52 ` Nicolas Goaziou
2022-03-23 16:30 ` Max Nikulin
2022-03-23 23:04 ` Nicolas Goaziou
2022-03-25 16:30 ` Max Nikulin
2022-03-27 15:38 ` John Kitchin
2022-03-27 23:18 ` Bruce D'Arcus
2022-03-20 13:32 ` Bruce D'Arcus
2022-03-20 13:42 ` Ihor Radchenko
2022-03-20 18:12 ` Thomas S. Dye
2022-03-20 20:13 ` Dominik Schrempf
2022-03-20 20:30 ` Vikas Rawal
2022-03-20 20:34 ` Bruce D'Arcus
2022-03-20 22:10 ` Dominik Schrempf
2022-03-20 19:44 ` Bruce D'Arcus
2022-03-20 21:14 ` chris
2022-03-21 14:21 ` John Kitchin
2022-03-21 14:10 ` John Kitchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m24k3jnq0k.fsf@andrew.cmu.edu \
--to=jkitchin@andrew.cmu.edu \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=vikasrawal@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).