From: "Bruce D'Arcus" <bdarcus@gmail.com>
To: John Kitchin <jkitchin@andrew.cmu.edu>
Cc: Vikas Rawal <vikasrawal@gmail.com>,
org-mode-email <emacs-orgmode@gnu.org>,
Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: citations: org-cite vs org-ref 3.0
Date: Sun, 27 Mar 2022 19:17:16 -0400 [thread overview]
Message-ID: <CAF-FPGPmmnuSwZPUnZWJje_2zs0Bdm+E3ALtiDT9F3VOP4dKAw@mail.gmail.com> (raw)
In-Reply-To: <m24k3jnq0k.fsf@andrew.cmu.edu>
On Sun, Mar 27, 2022 at 3:41 PM John Kitchin <jkitchin@andrew.cmu.edu> wrote:
...
> 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?
You mean why shouldn't we privilege natbib, as you have in org-ref?
And let me turn the question around: how would you propose to
translate those natbib-derived commands to biblatex, or CSL, so it
works reliably across users and documents? The mapping has to happen
someplace, after all.
And from a UX POV, how well would that work for users who have no
previous experience with natbib or even latex?
...
> 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 think what Nicolas is asking is when you have time, to itemize the
pain points that made development difficult for you, so that we might
figure out how to improve them (perhaps new helper functions, etc.).
As another data point, one of the things I've loved about org-cite is
how easy I found it to develop pretty functional processors for citar
with minimal code. Total LOC for citar is just under 2000, with just
under 400 specific to org.
But I'm deliberately developing a small, focused, modular, package.
...
> 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.
The org-cite citation syntax and model, I hope you would agree, is
unambiguously better than natbib or the original org-ref syntax. It's
simpler than biblatex in the sense of no difference between single and
multicite citations, but can easily and losslessly map to and from
either.
Org-ref 3.0 adds essentially a copy of that syntax and model, with a
trivial difference.
To me, that's the biggest problem. Aside from users having
incompatible documents, it forces other developers either to dedicate
additional development and maintenance time to supporting both
syntaxes, or to choose one.
Pandoc only supports org-cite.
In the case of citar, I have also decided to only support org-cite
(though I leave the function to generate citations configurable, so
it's easy enough for a user to configure this themselves; but I don't
include this by default because I have other processor code that
relies on parsed citations).
Org-roam supports all three.
It sounds like the biggest hold up was with reconciling the org-ref
command model with more general approach of the oc style and variants.
But as a first step, you could do as you originally planned to: simply
use the same names for styles. If Nicolas were to allow the mapping in
natbib to be handled via the defcustom, you could even do this without
having to write and maintain your own export processor.
And then you could save the other part (how to map those to other
export processors) for another step, if and when you or your users
need it or want it.
Certainly that would address the most fundamental incompatibility.
I guess to be direct: what value does the v3 syntax provide you, your
users, or the org ecosystem in general?
Bruce
next prev parent reply other threads:[~2022-03-27 23:17 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
2022-03-27 23:17 ` Bruce D'Arcus [this message]
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=CAF-FPGPmmnuSwZPUnZWJje_2zs0Bdm+E3ALtiDT9F3VOP4dKAw@mail.gmail.com \
--to=bdarcus@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=jkitchin@andrew.cmu.edu \
--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).