From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: emacs-orgmode@gnu.org
Subject: Re: Citations, continued
Date: Mon, 09 Feb 2015 09:46:35 -0800 [thread overview]
Message-ID: <86wq3rrn9g.fsf@berkeley.edu> (raw)
In-Reply-To: m2wq3s11qg.fsf@tsdye.com
Hi Tom and all,
tsd@tsdye.com (Thomas S. Dye) writes:
> IIUC, Org mode citation syntax needs to capture four pieces of
> information for an *individual* citation: a =key= into one or more
> stores of bibliographic information; a =citation-command= that is
> understood by the =citation-style= specified for the document; a
> =pre-note= of arbitrary text in any language; and a =post-note= of
> arbitrary text in any language. At least, this is how the LaTeX world
> accommodates the almost unconstrained and ever-growing variability in
> bibliographic styles in the wild.
I think the key, pre-note and post-note are common ground, and everyone
agrees that they need to be represented in a citation syntax.
I am a bit more hesitant about the citation command, though. My reasons
for hestitation are the same as other people have expressed here, but I
think it might be useful to summarize.
As Tom notes, there is basically unlimited complexity in the LaTeX world
for citation commands. There's a different subset of commands for every
distinction you might want to express in a given style.
The trouble is that there is close to zero support for this complexity
in the other export formats that Org supports. As far as I am aware
(though I could be wrong), HTML, ODT, and other document formats barely
even have a way of indicating that a piece of text is a citation.
(HTML5 does have a "cite" element, but it seems to be basically an
unconstrained semantic element.)
Many of us (including me) are exporting to LaTeX, and if that is what
you are doing, it is natural to want to have access to all the
distinctions that LaTeX provides. But if we try to capture those
distinctions in a high-level Org citation syntax, then we have two
problems: (a) finding the right syntax to express those distinctions,
and (b) exporting citations that make use of those distinctions to
non-LaTeX formats, which provide little support for them. The more
distinctions we try to capture, the more difficult these problems will
be to solve.
Thus, I think the right question to ask is: which distinctions are both
*simple enough* and *important enough* that they are worth encoding in
Org syntax and supporting in non-LaTeX backends? I think that is the
right place to draw the line between features of citations that are
encoded in `citation syntax proper' vs. `escape hatches' that give more
information about how to format a citation in a particular backend.
My sense is that a lot of the complexity in LaTeX citations should fall
in the latter category, but we need to think more about what falls in
the first category.
One clear candidate for the first category that I think everyone agrees
on is the distinction between in-text vs. parenthetical citations
(\citet vs. \citep and similar in LaTeX). For my own case, this is the
only distinction I need to be directly expressed in syntax.
Nicolas expressed a similar opinion:
> It seems to me that :type is a LaTeX-only feature and, as such, should
> be handled in "ox-latex". In the general case, I think that Org should
> only support inline and parenthesized citations.
But in response to a question from Rasmus, Tom also suggested that
multi-cites are a candidate, in addition to the in-text/parenthetical
distinction:
> Yes, I typically use what I call a multicite to get multiple citations
> with biblatex.
I myself never use these, so I don't understand exactly what would be
required to support them properly in non-LaTeX backends, and I can't
speak to which category they belong to.
Are there other candidates we should discuss? What other distinctions
are so important that they are worth figuring out how to express in
syntax that can be exported by all backends?
As for supporting the `escape hatch' category, it seems that more
thought is needed here, too. Right now, the #+ATTR_BACKEND syntax is
the only way I know of to specify arbitrary export properties for a
piece of Org syntax. But it only applies to greater elements, and Tom
at least does not think it is sufficient to only allow specifying the
citation command, in particular, in an out-of-line (because greater
element) citation definition.
So maybe we need some kind of inline syntax for backend-specific
properties of citations, perhaps along the lines that Rasmus has
suggested. I think this could be a good idea; my only concern is that
we make a clear separation between this syntax and the main syntax for
citations. There are two reasons for this: if we don't clearly make
this separation, then (1) it becomes much harder to figure out and agree
on which distinctions should be expressed in `the' citation syntax; and
(2) there is a danger that the complexity of backend-specific properties
will bleed over into the main citation syntax, which all backends have
to support.
Best,
Richard
next prev parent reply other threads:[~2015-02-09 17:46 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-31 18:26 Citations, continued Richard Lawrence
2015-01-31 18:42 ` Nicolas Goaziou
2015-02-01 22:07 ` Richard Lawrence
2015-02-02 13:52 ` Rasmus
2015-02-02 17:25 ` Richard Lawrence
2015-02-02 18:09 ` Rasmus
2015-02-02 15:45 ` Erik Hetzner
2015-02-01 22:06 ` John Kitchin
2015-02-02 1:41 ` Richard Lawrence
2015-02-02 4:43 ` Thomas S. Dye
2015-02-02 13:56 ` John Kitchin
2015-02-02 18:11 ` Thomas S. Dye
2015-02-02 19:38 ` John Kitchin
2015-02-02 19:51 ` John Kitchin
2015-02-02 22:47 ` Rasmus
2015-02-03 0:54 ` Thomas S. Dye
2015-02-03 1:36 ` John Kitchin
2015-02-02 14:17 ` Rasmus
2015-02-02 16:58 ` Richard Lawrence
2015-02-02 14:07 ` Rasmus
2015-02-02 13:51 ` Rasmus
2015-02-02 15:09 ` Matt Price
2015-02-02 18:02 ` Richard Lawrence
2015-02-02 19:55 ` Rasmus
2015-02-03 1:56 ` Richard Lawrence
2015-02-03 2:08 ` Vikas Rawal
2015-02-03 10:55 ` Rasmus
2015-02-04 10:35 ` Julian M. Burgos
2015-02-04 16:34 ` John Kitchin
2015-02-03 10:35 ` Rasmus
2015-02-03 12:00 ` Eric S Fraga
2015-02-03 16:27 ` Richard Lawrence
2015-02-03 17:25 ` Eric S Fraga
2015-02-03 3:58 ` Erik Hetzner
2015-02-03 4:41 ` Richard Lawrence
2015-02-03 7:30 ` Erik Hetzner
2015-02-03 16:11 ` Richard Lawrence
2015-02-04 6:30 ` Erik Hetzner
2015-02-04 12:06 ` Nicolas Goaziou
2015-02-04 16:45 ` Richard Lawrence
2015-02-06 10:27 ` Nicolas Goaziou
2015-02-06 22:41 ` Richard Lawrence
2015-02-07 22:43 ` Nicolas Goaziou
2015-02-08 2:46 ` Richard Lawrence
2015-02-08 9:46 ` John Kitchin
2015-02-08 17:09 ` Richard Lawrence
2015-02-08 22:23 ` Thomas S. Dye
2015-02-09 8:46 ` e.fraga
2015-02-09 10:50 ` Rasmus
2015-02-09 11:20 ` Nicolas Goaziou
2015-02-09 11:37 ` Rasmus
2015-02-10 9:06 ` Nicolas Goaziou
2015-02-09 15:09 ` Thomas S. Dye
2015-02-10 8:55 ` Nicolas Goaziou
2015-02-10 9:22 ` Rasmus
2015-02-10 9:41 ` Nicolas Goaziou
2015-02-10 10:01 ` Rasmus
2015-02-10 15:32 ` Thomas S. Dye
2015-02-10 1:50 ` John Kitchin
2015-02-09 17:46 ` Richard Lawrence [this message]
2015-02-09 20:13 ` Rasmus
2015-02-10 1:32 ` John Kitchin
2015-02-10 4:04 ` Richard Lawrence
2015-02-10 5:23 ` John Kitchin
2015-02-10 6:20 ` Thomas S. Dye
2015-02-08 9:58 ` Nicolas Goaziou
2015-02-08 17:18 ` Richard Lawrence
2015-02-08 18:18 ` Nicolas Goaziou
2015-02-08 9:28 ` Rasmus
2015-02-08 10:18 ` Nicolas Goaziou
2015-02-08 10:50 ` Rasmus
2015-02-08 12:36 ` Nicolas Goaziou
2015-02-08 13:40 ` Rasmus
2015-02-08 16:11 ` Nicolas Goaziou
2015-02-09 10:02 ` Rasmus
2015-02-08 17:02 ` Nicolas Goaziou
2015-02-08 17:29 ` Rasmus
2015-02-10 1:54 ` John Kitchin
2015-02-10 8:49 ` Nicolas Goaziou
2015-02-10 9:20 ` Rasmus
2015-02-10 10:05 ` Nicolas Goaziou
2015-02-10 10:36 ` Rasmus
2015-02-10 10:53 ` Andreas Leha
2015-02-10 15:03 ` John Kitchin
2015-02-10 15:54 ` Rasmus
2015-02-10 16:14 ` John Kitchin
2015-02-10 16:22 ` Richard Lawrence
2015-02-10 16:44 ` Stefan Nobis
2015-02-11 2:07 ` Richard Lawrence
2015-02-11 10:19 ` Stefan Nobis
2015-02-11 16:51 ` Richard Lawrence
2015-02-13 2:31 ` Matt Price
2015-02-11 10:47 ` Aaron Ecay
2015-02-11 11:32 ` Rasmus
2015-02-10 16:04 ` Richard Lawrence
2015-02-11 2:10 ` Thomas S. Dye
2015-02-11 2:48 ` Richard Lawrence
2015-02-11 3:53 ` Thomas S. Dye
2015-02-06 23:37 ` Rasmus
2015-02-06 23:16 ` Rasmus
2015-02-04 17:44 ` Erik Hetzner
2015-02-04 15:59 ` Richard Lawrence
2015-02-04 17:58 ` Erik Hetzner
2015-02-04 19:24 ` Richard Lawrence
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=86wq3rrn9g.fsf@berkeley.edu \
--to=richard.lawrence@berkeley.edu \
--cc=emacs-orgmode@gnu.org \
/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).