Re: [O] Citations, continued

[Nicolas Goaziou]

Rasmus <address@hidden> writes:

> Nicolas Goaziou <address@hidden> writes:
>
>> Using the example from Erik Hetzner in the same thread, what about:
>>
>>   1. [cite:@item1] says blah.
>>   2. [cite:@item1: p. 30] says blah.
>
> Why is "p." stripped here?

I don't understand. Anyway, I now suggest

  address@hidden and address@hidden p. 30]

>>   3. [cite:@item1: p. 30, with suffix] says blah.
>>   4. [cite:@item1: address@hidden 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.

  address@hidden address@hidden p. 30]

Downgrade is a bit strong.

>>   5. A citation group [cite:: see @item1 p. 34-35; also @item3 chap. 3].
>
> Why is chap. *not* stripped here?

I do not understand either.

> Where does suffix and locator end here.  E.g. what is the output of
>
>      [cite:: @item1 33, pp. 35-37, and nowhere else].

  [cite: @item1 pp. 33, 35-37, and nowhere else]

suffix and locator are merged (AFAIU, in practice, there is no
distinction between locator and suffix): "pp. 33, 35-37, and nowehere
else".

>>   9. Citation with suffix only [cite:: @item1 and nowhere else].
>
> How do I know this is a suffix?  Is locator a regexp like 
>     \`[p\.0-9 ]+?

See above.

> What is [cite:@K s. 12] or [cite:@K side.? 12]?

See above.

> 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:

  address@hidden address@hidden, and address@hidden

> Some comments.
> 
>   1. Am I supposed to distinguish between a text citations and parenthesis
>      citation based on a single ":"?  That's hard.  Why not distinguish
>      based on the initial label?  E.g. {textcite, parentcite} or {citet,
>      citep}.

In fact, you're right, we don't need the colon, hence my other proposal.

>   2. The idea of locator /and/ suffix is confusing.  The fact that your
>      examples suggest seemingly random dropping of data from locator makes
>      me want to avoid it even more.  It's a 'can of worms' to use a
>      frequently emerging expression from this list.

Again, there's no real need to extract a locator. At least, not at the
parser level.

>   3. This is almost full circle.  The proposal above seems no better (and
>      IMO worse) than e.g. the generalized links that Tom suggested, e.g.
>      [TYPE: KEY :pre PRE :post SUF] or [TYPE: PRE @KEY POST]. 
>      Or [[TYPE: KEY :pre PRE :post SUF]] or [[TYPE: PRE @KEY POST]].

In [type: KEY :pre PRE :post SUF], PRE comes after KEY, which impedes
readability, IMO.

Double brackets are link syntax: there will be conflict if TYPE belongs
to `org-link-types'.

>   5. . . . Yet I still don't know how to get A1 (PRE Y2) with the above.
>      Is the benchmark correct?

You can't. Is this needed?

> If parsing speed is key here I think that
> [citet: pre1 @k1 post1; pre2 @k2 post2] and [citep: pre1 @k1 post1; pre2 @k2 
> post2]
> are clearer solutions.  But this is clearly closer to a LaTeX than
> pandoc.

If "A1 (PRE Y2)" is really needed, then yes, I think that's good enough.
Otherwise I think address@hidden is terse and nice.


Regards,