Richard Lawrence <richard.lawre...@berkeley.edu> writes:
> t...@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.
False. There has been discussions as to whether prenote should be
included for inline citations.
> 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.
Ideally we find TOOL that can handle this. Worse case: bibtex.el, but
hopefully something less bare-bone, that knows about styles would be
great. E.g. "Zotero for html" or similar.
> 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.
I don't know. If you think of a type as a receipt it makes sense to allow
it to some extend, I guess. Most LaTeX "receipts" very easy to use 'cause
somebody took care of the details.
> 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:
Multicite is pretty easy. A couple of days ago I showed that you can even
do it with the current link syntax.
Examples:
\textcites(pre-both)(post-both)[pre1][post1]{bohringer14}[pre2][post2]{davis14}
→ pre-both Böhringer et al. (pre1 2014, post1) and Davis and Schiraldi (pre2
2014, post2), post-both
\parencites(pre-both)(post-both)[pre1][post1]{bohringer14}[pre2][post2]{davis14}
→ (pre-both pre1 Böhringer et al. 2014, post1; pre2 Davis and Schiraldi 2014,
post2, post-both)
But multicite is surely a ox-latex feature, but it's just a convenience
wrapper around normal cite commands which can be constructed using
primitives, namely :author, :year :pre and :post. You could imagine
something like
[cite: pre-both; pre1 @k1 post1; pre2 @k2 post2; post-both]
Which could be simplified to
[cite: pre-both pre1 @k1 post1; pre2 @k2 post2 post-both]
> 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.
>From a user perspective, links take a backend argument.
> 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.
Those are indeed valid concerns. One reason why I like :type is that all
complexity is hidden away somewhere else. Much like links. This may not
be a good thing. I'm heating up on (my interpretation) of Nicolas
idea:
[cite: pre-both; pre1 @k1 post1; pre2 @k2 post2; post-both]
It's still an improvement (though small) over links, and you might still
get one "free" type which can be expressed as [@k].
—Rasmus
--
What will be next?
