Re: Citations, continued

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Rasmus <rasmus@gmx.us> writes:

>>>>  2. [cite:@item1: p. 30] says blah.
>>>> ...              ^^^^
>>>>  2.   Doe (2005, 30) says blah.
>>>>                ^^^

According to Erik, this is just a possible output. It belongs to export
configuration.

>>>>   3. [cite:@item1: p. 30, with suffix] says blah.
>>>>   4. [cite:@item1: -@item2 p. 30; see also @item3] says blah.
>>>
>>> If item{1,2} have the same author biblatex[-chicago?] is smart enough to
>>> compress it to "author (year1, year2)". So this example seems like a
>>> downgrade if "-" is required to get the suggested output.
>>
>>   [@item1 -@item2 p. 30]
>>
>> Downgrade is a bit strong.
>
> If I have to think about the /formatting/ out output rather than the
> /contents/ downgrade is not too strong (IMO).  In the example above, why
> not [@item1 @item2 p. 30]?

All back-end may not be smart enough to compress years. However, it is
probably equivalent for those that can.

> Another issue is that it's not transpose-words safe.  E.g. this output
> seems bad: [-@k1 @k2 30] => Y1 A2 (Y2, 30).

This citation is invalid. The point of [@k1] is that the author is
mandatory, since it is in-text, so [-@k1] doesn't make sense. 

Also, it is not possible (as in Pandoc) to extract only year from
a bibliography entry, so there's no way to have Y1 so far.

> But in your previous examples data is stripped from the locator.  If
> there's no difference I think it would be better to not talk about this
> locator 'cause it's extremely confusing.

Again, I was re-using examples. Let's forget about the "locator".

> See also above.  From you explanation I would guess that at least these
> two examples are wrong.  Is that correct?
>
>>>>  2. [cite:@item1: p. 30] says blah.
>>>>  2.   Doe (2005, 30) says blah.
>>>>  3. [cite:@item1: p. 30, with suffix] says blah.
>>>>  3.   Doe (2005, 30, with suffix) says blah.

They are not wrong. The output may decide to strip "p. ". This is not
our problem at this stage of the discussion.

>>> What if I need several text cite keys.  Say @K{1,2} is the same author A,
>>> and @K3 is B.  Then  [cite:@K1,@K2,@K3] should/could be something like 
>>> A (Y1, Y2), and B (Y3).  How do I express this?
>>
>> Since A and B do not appear in the same parenthesis, two citations are
>> needed:
>>
>>   [@K1 -@K2], and [@K3]
>
> This is a minor downgrade from biblatex.  The year thing is worse.

Org doesn't pretend to replace either LaTeX or biblatex. If extracting
data from an entry is required, then I suggest to extend key syntax,
e.g.:

  @K1:year

But, again, if this is a LaTeX-only feature, org-ref and even raw LaTeX
code is good enough. We shouldn't try to implement every possible
feature, or we will fail.

So, it is only an option if it can be implemented in most major export
back-ends.

> It's not unheard of.  I have used it in the past.  In LaTeX it's something like: 
>
>     \citet[C]{k}    → A    (Y, C)
>     \citet[B][]{k}  → A (B, Y)
>     \citet[B][C]{k} → A (B, Y, C)

I understand, but would it be needed to have both A (Y, C) and A (B, Y)
in the same document? Otherwise, [@k text] can be treated either as
A (text, Y) or A (Y, text) consistently throughout the document,
according to bibliographic style.

In any case, if we allow @key:tag syntax, then it is possible to do

  [@k:author] [cite: B -@k C]

and get

  A (B, Y, C)

> It's nice. @k1 / [pre @k1 post] for text and (pre @k1 post) for
> parentheses expressions is nicer, but that's details. I trust your
> judgment on the technical merit of one idea versus the next.

[pre @k1 post] is slower to parse. (pre @k1 post) is worse because "("
is probably more common than "[". Really, round brackets should not be
used for Org syntax.

I haven't much against @k1, but it introduces more false positives than
[@k1].

Regards,