From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Rasmus <rasmus@gmx.us>
Cc: emacs-orgmode@gnu.org
Subject: Re: Citations, continued
Date: Sun, 08 Feb 2015 13:36:07 +0100 [thread overview]
Message-ID: <87bnl4shqg.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87vbjcoewx.fsf@gmx.us> (rasmus@gmx.us's message of "Sun, 08 Feb 2015 11:50:38 +0100")
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,
next prev parent reply other threads:[~2015-02-08 12:35 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 [this message]
2015-02-08 13:40 ` Rasmus
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=87bnl4shqg.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/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).