Re: [O] Citations, continued

[Rasmus]

Nicolas Goaziou <address@hidden> writes:

>> Another issue is that it's not transpose-words safe.  E.g. this output
>> seems bad: address@hidden @k2 30] => Y1 A2 (Y2, 30).
>
> This citation is invalid. The point of address@hidden is that the author is
> mandatory, since it is in-text, so address@hidden doesn't make sense. 

In that case I prefer the explicit extraction of keys below, since I don't
understand why address@hidden is invalid ("in her seminal address@hidden 
@k:journal article,
@k:author demonstrated that ⋯").  Probably I don't understand pandoc well
enough...

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

It seemed to be the main characteristics of this "locator" that you all
were talking about...

>>>> 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
>>
>> This is a minor downgrade from biblatex.  The year thing is worse.
>
> Org doesn't pretend to replace either LaTeX or biblatex.

Of course not.  That would be idiotic.  But I would rather try to imitate
the state-of-the-art, which in my book is biblatex, not pandocs.

> If extracting data from an entry is required, then I suggest to extend
> key syntax, e.g.:
>
>   @K1:year

Extracting from a plist-like thingy is easy.  What is hard is proper
formatting of things like author, e.g. how many author to include, adding
"and" etc.  It would be amazing to let TOOL handle this!  Unfortunately,
good TOOL is scare outside of the latex-world (maybe Zotero?  I don't know
how commandline friend it is).

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

Sure, why not?  The citation is often an active part of the sentence in
author-year style ("⋯ as AUTHOR-TEAM (see e.g. 1993, chapter 3) ⋯").  In
my experience postnotes are much more common, though.

> In any case, if we allow @key:tag syntax, then it is possible to do
>
>   address@hidden:author] [cite: B address@hidden C]
>
> and get
>
>   A (B, Y, C)

OK.  I don't particularly like it.  E.g. when I find out that the abstract
of @k was misleading and that @KK is the right citation I have to
carefully change @k to @KK two places.  This is probably minor, though.

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

Is that because you'd have to check all occurrences or [⋯]?

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

Probably true.

> I haven't much against @k1, but it introduces more false positives than
> address@hidden

It could check if k1 is a known key and interpret "@k1" accordingly.  In
my limited experience with bibtex.el it's only a bit slow to look up a key
the first time.  But who knows how this scale on very citation-intensive
documents.

On the interwebs some people use @USERNAME a lot (maybe it's a google
thing?).  That might speak against this.

—Rasmus

PS: Here's a quick link "proof-of-concept" (not really) with biblatex
only, and cite it textcitation.  Documents with this type of syntax are
indeed pleasant to the eye.

[[cite: pre1 @bohringer14 post1; pre2 @davis14 post2]]
→ \textcites[pre1][post1]{bohringer14}[pre2][post2]{davis14}

(org-add-link-type
 "cite"
 'identity
 (lambda (path description backend)
   (funcall 'rasmus/org-bib-format path description backend "textcite")))

(defun rasmus/interpret-cite-string (string)
  (mapcar
   (lambda (data)
     (string-match "\\(address@hidden)@\\([^ \t]*\\)\\(address@hidden)" data)
     (list :key (match-string 2 data)
           :pre (org-trim (or (match-string 1 data) ""))
           :post (org-trim (or (match-string 3 data) "")))) 
   (org-split-string string ";")))

(defun rasmus/org-bib-format (path description backend type)
  (let ((citations (rasmus/interpret-cite-string path)))
    (if (org-export-derived-backend-p backend 'latex)
        (format "\\%s%s%s"
                type (if (> (length citations) 1) "s" "")
                (mapconcat (lambda (cite)
                             (format "[%s][%s]{%s}" (plist-get cite :pre)
                                     (plist-get cite :post)
                                     (plist-get cite :key)))
                           citations "")))))


-- 
Summon the Mothership!