From: Rasmus <rasmus@gmx.us>
To: emacs-orgmode@gnu.org
Subject: Re: Citations, continued
Date: Sun, 08 Feb 2015 14:40:18 +0100 [thread overview]
Message-ID: <87h9uwwmgt.fsf@gmx.us> (raw)
In-Reply-To: 87bnl4shqg.fsf@nicolasgoaziou.fr
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>> 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.
In that case I prefer the explicit extraction of keys below, since I don't
understand why [-@k1] is invalid ("in her seminal -@k @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:
>>>
>>> [@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.
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
>
> [@k:author] [cite: B -@k 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
> [@k1].
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 "\\([^@]*\\)@\\([^ \t]*\\)\\([^@]*\\)" 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!
next prev parent reply other threads:[~2015-02-08 13:40 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-31 18:26 Citations, continued Richard Lawrence
2015-01-31 18:42 ` Nicolas Goaziou
2015-02-01 22:07 ` Richard Lawrence
2015-02-02 13:52 ` Rasmus
2015-02-02 17:25 ` Richard Lawrence
2015-02-02 18:09 ` Rasmus
2015-02-02 15:45 ` Erik Hetzner
2015-02-01 22:06 ` John Kitchin
2015-02-02 1:41 ` Richard Lawrence
2015-02-02 4:43 ` Thomas S. Dye
2015-02-02 13:56 ` John Kitchin
2015-02-02 18:11 ` Thomas S. Dye
2015-02-02 19:38 ` John Kitchin
2015-02-02 19:51 ` John Kitchin
2015-02-02 22:47 ` Rasmus
2015-02-03 0:54 ` Thomas S. Dye
2015-02-03 1:36 ` John Kitchin
2015-02-02 14:17 ` Rasmus
2015-02-02 16:58 ` Richard Lawrence
2015-02-02 14:07 ` Rasmus
2015-02-02 13:51 ` Rasmus
2015-02-02 15:09 ` Matt Price
2015-02-02 18:02 ` Richard Lawrence
2015-02-02 19:55 ` Rasmus
2015-02-03 1:56 ` Richard Lawrence
2015-02-03 2:08 ` Vikas Rawal
2015-02-03 10:55 ` Rasmus
2015-02-04 10:35 ` Julian M. Burgos
2015-02-04 16:34 ` John Kitchin
2015-02-03 10:35 ` Rasmus
2015-02-03 12:00 ` Eric S Fraga
2015-02-03 16:27 ` Richard Lawrence
2015-02-03 17:25 ` Eric S Fraga
2015-02-03 3:58 ` Erik Hetzner
2015-02-03 4:41 ` Richard Lawrence
2015-02-03 7:30 ` Erik Hetzner
2015-02-03 16:11 ` Richard Lawrence
2015-02-04 6:30 ` Erik Hetzner
2015-02-04 12:06 ` Nicolas Goaziou
2015-02-04 16:45 ` Richard Lawrence
2015-02-06 10:27 ` Nicolas Goaziou
2015-02-06 22:41 ` Richard Lawrence
2015-02-07 22:43 ` Nicolas Goaziou
2015-02-08 2:46 ` Richard Lawrence
2015-02-08 9:46 ` John Kitchin
2015-02-08 17:09 ` Richard Lawrence
2015-02-08 22:23 ` Thomas S. Dye
2015-02-09 8:46 ` e.fraga
2015-02-09 10:50 ` Rasmus
2015-02-09 11:20 ` Nicolas Goaziou
2015-02-09 11:37 ` Rasmus
2015-02-10 9:06 ` Nicolas Goaziou
2015-02-09 15:09 ` Thomas S. Dye
2015-02-10 8:55 ` Nicolas Goaziou
2015-02-10 9:22 ` Rasmus
2015-02-10 9:41 ` Nicolas Goaziou
2015-02-10 10:01 ` Rasmus
2015-02-10 15:32 ` Thomas S. Dye
2015-02-10 1:50 ` John Kitchin
2015-02-09 17:46 ` Richard Lawrence
2015-02-09 20:13 ` Rasmus
2015-02-10 1:32 ` John Kitchin
2015-02-10 4:04 ` Richard Lawrence
2015-02-10 5:23 ` John Kitchin
2015-02-10 6:20 ` Thomas S. Dye
2015-02-08 9:58 ` Nicolas Goaziou
2015-02-08 17:18 ` Richard Lawrence
2015-02-08 18:18 ` Nicolas Goaziou
2015-02-08 9:28 ` Rasmus
2015-02-08 10:18 ` Nicolas Goaziou
2015-02-08 10:50 ` Rasmus
2015-02-08 12:36 ` Nicolas Goaziou
2015-02-08 13:40 ` Rasmus [this message]
2015-02-08 16:11 ` Nicolas Goaziou
2015-02-09 10:02 ` Rasmus
2015-02-08 17:02 ` Nicolas Goaziou
2015-02-08 17:29 ` Rasmus
2015-02-10 1:54 ` John Kitchin
2015-02-10 8:49 ` Nicolas Goaziou
2015-02-10 9:20 ` Rasmus
2015-02-10 10:05 ` Nicolas Goaziou
2015-02-10 10:36 ` Rasmus
2015-02-10 10:53 ` Andreas Leha
2015-02-10 15:03 ` John Kitchin
2015-02-10 15:54 ` Rasmus
2015-02-10 16:14 ` John Kitchin
2015-02-10 16:22 ` Richard Lawrence
2015-02-10 16:44 ` Stefan Nobis
2015-02-11 2:07 ` Richard Lawrence
2015-02-11 10:19 ` Stefan Nobis
2015-02-11 16:51 ` Richard Lawrence
2015-02-13 2:31 ` Matt Price
2015-02-11 10:47 ` Aaron Ecay
2015-02-11 11:32 ` Rasmus
2015-02-10 16:04 ` Richard Lawrence
2015-02-11 2:10 ` Thomas S. Dye
2015-02-11 2:48 ` Richard Lawrence
2015-02-11 3:53 ` Thomas S. Dye
2015-02-06 23:37 ` Rasmus
2015-02-06 23:16 ` Rasmus
2015-02-04 17:44 ` Erik Hetzner
2015-02-04 15:59 ` Richard Lawrence
2015-02-04 17:58 ` Erik Hetzner
2015-02-04 19:24 ` Richard Lawrence
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h9uwwmgt.fsf@gmx.us \
--to=rasmus@gmx.us \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).