Re: [O] Citations, continued

[Rasmus]

Richard Lawrence <address@hidden> writes:

> address@hidden (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 address@hidden

—Rasmus

-- 
What will be next?