From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: emacs-orgmode@gnu.org
Subject: Re: Citation syntax: a revised proposal
Date: Sun, 15 Feb 2015 10:07:27 -0800 [thread overview]
Message-ID: <873867m4kg.fsf@berkeley.edu> (raw)
In-Reply-To: 87zj8fjdnv.fsf@nicolasgoaziou.fr
Hi Nicolas,
Thanks for your comments. A couple of replies follow.
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>> The difference between parenthetical and in-text citations is
>> expressed using parentheses around the /first/ citation key. A
>> parenthetical citation has such parentheses around the first citation
>> key; an in-text citation lacks them. (Parentheses around non-initial
>> keys are permitted for visual consistency and to keep the grammar
>> simple, but have no meaning.)
>
> I think it would be nicer to differentiate between in-text and
> parenthetical citations at the type level, e.g.:
>
>
> [cite: this @key citation is in-text]
> [(cite): this @key citation is parenthetical]
>
> or, as already suggested
>
> [citet: ...]
> [citep: ...]
>
> I prefer the former.
Either of these is fine with me if it is OK with you. I was trying to
avoid any variation in the position after `[' to reduce strain on the
parser, but if these are simple enough to support without too many false
positives, even better.
>> This additional information may be supplied following the brackets of
>> a citation between the following delimiters: `%%( ... )'.
>
> As pointed out, this is very odd. But I cannot see any clean solution.
As I said in reply to Rasmus, my only reason for this choice was to be
consistent with the s-expression syntax in timestamps and capture
templates. I am fine with (and even would prefer) something that looks
prettier.
> However, it would be nice to integrate it somehow with the syntax. Maybe
> something like
>
> [cite: ... @key ...; ... @key2 ... |latex: :prop val |html: :prop val]
>
But I think there are three reasons this does not quite improve on what
I proposed:
1) It looks like it only supports properties directed at specific
backends. How should users specify custom properties that they want to
be handled in multiple backends (by their own filter)?
2) It requires us to decide *now* on conventions for specifying
properties to specific backends (and also to build a parser for them,
instead of just calling `read'), instead of just using arbitrary
s-expressions and seeing what people come up with in the future. (See
my reply to Tom for more about how I was thinking this part of the
syntax would evolve.)
3) Putting the properties inside the brackets introduces an (admittedly
very minor) additional restriction on suffix text, and can't be used
with the simple syntax for in-text citations. (See my reply to Rasmus
on this point.)
That said, I have no objections to doing something like this if we can
come to an agreement now about what it should look like.
>> ** Outstanding issues
>> It seems to me that there are potential problems with the above
>> proposal in a number of areas, but I cannot tell how serious they are,
>> or what changes (if any) should be made to solve them. I don't
>> pretend that this is an exhaustive list:
>> 1) *Nesting.* I have favored LaTeX compatibility for in-text
>> citations with multiple references; but this means there is no
>> way to `nest' citations. Thus, there is no way to express (in
>> the main syntax) what Pandoc expresses as:
>> @Doe99 [p. 34; see also @DoeRoe2000]
>> which renders like:
>> Doe (1999, p. 34; see also Doe and Roe 2000)
>> Instead, since a citation is in-text or parenthetical as a whole,
>> the equivalent in the above syntax
>> [cite: @Doe99 p. 34; see also @DoeRoe2000]
>> should render like:
>> Doe (1999, p. 34), see also Doe and Roe (2000).
>> I am not certain if Pandoc-like output is important in this case.
>> The few people who commented on this said that it was not.
>
> AFAIU, when using in-text citation, only the first key is extracted out
> of the parenthesis, so
>
> [cite: @Doe99 p. 34; see also @DoeRoe2000]
>
> should really render like
>
> Doe (1999, p. 34; see also Doe and Roe 2000).
>
> IOW, why do you think that "a citation is in-text or parenthetical as
> a whole"?
This is a LaTeX compatibility issue, and it is an area where Pandoc
departs from LaTeX behavior. If you're a LaTeX user, the natural way to
think of the Org syntax you quoted is (I think) as equivalent to one of:
\textcites[p. 34]{Doe99}[see also][]{DoeRoe2000}
\textcite[p. 34]{Doe99}, \textcite[see also][]{DoeRoe2000}
which IIUC both render like
Doe (1999, p. 34), see also Doe and Roe (2000).
modulo some subtle details about the separator. No one so far has said
that they need or want the Pandoc behavior. I personally am fine
without it.
Best,
Richard
next prev parent reply other threads:[~2015-02-15 18:08 UTC|newest]
Thread overview: 163+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-15 2:29 Citation syntax: a revised proposal Richard Lawrence
2015-02-15 2:45 ` Richard Lawrence
2015-02-15 3:57 ` Thomas S. Dye
2015-02-15 16:40 ` Richard Lawrence
2015-02-15 19:43 ` Thomas S. Dye
2015-02-16 3:34 ` Matt Price
2015-02-16 8:56 ` Nicolas Goaziou
2015-02-16 9:57 ` Rasmus
2015-02-17 17:18 ` Richard Lawrence
2015-02-17 18:11 ` Rasmus
2015-02-18 0:44 ` Matt Price
2015-02-18 3:38 ` Richard Lawrence
2015-02-18 2:24 ` Thomas S. Dye
2015-02-18 4:03 ` Richard Lawrence
2015-02-18 9:00 ` Stefan Nobis
2015-02-18 10:11 ` Eric S Fraga
2015-02-18 14:19 ` Nicolas Goaziou
2015-02-18 16:38 ` Richard Lawrence
2015-02-18 18:44 ` Samuel Wales
2015-02-18 18:46 ` Samuel Wales
2015-02-18 20:54 ` Aaron Ecay
2015-02-18 21:21 ` Samuel Wales
2015-02-18 21:24 ` John Kitchin
2015-02-18 19:42 ` Nicolas Goaziou
2015-02-18 20:47 ` Aaron Ecay
2015-02-18 22:43 ` Rasmus
2015-02-18 22:35 ` Rasmus
2015-02-19 17:06 ` Richard Lawrence
2015-02-20 0:10 ` Nicolas Goaziou
2015-02-20 16:44 ` Richard Lawrence
2015-02-20 19:45 ` Samuel Wales
2015-02-20 20:01 ` Rasmus
2015-02-20 22:33 ` Samuel Wales
2015-02-21 11:58 ` Rasmus
2015-02-21 17:25 ` Thomas S. Dye
2015-02-27 0:56 ` Samuel Wales
2015-02-27 8:55 ` Stefan Nobis
2015-02-27 9:56 ` Rasmus
2015-02-21 3:12 ` Richard Lawrence
2015-02-21 12:00 ` Rasmus
2015-02-21 20:19 ` Samuel Wales
2015-02-21 20:36 ` Samuel Wales
2015-02-25 13:59 ` Aaron Ecay
2015-02-25 16:57 ` Richard Lawrence
2015-02-25 22:37 ` Nicolas Goaziou
2015-02-26 5:10 ` Richard Lawrence
2015-03-01 20:35 ` Nicolas Goaziou
2015-03-01 21:31 ` Rasmus
2015-03-02 0:24 ` Thomas S. Dye
2015-03-02 8:57 ` Eric S Fraga
2015-03-02 1:37 ` Thomas S. Dye
2015-03-02 9:23 ` Rasmus
2015-03-02 19:11 ` Aaron Ecay
2015-03-02 20:15 ` Rasmus
2015-03-03 3:14 ` Richard Lawrence
2015-03-03 5:33 ` Avram Lyon
2015-03-03 17:27 ` Richard Lawrence
2015-03-03 17:56 ` Avram Lyon
2015-03-04 16:41 ` Richard Lawrence
2015-03-03 9:24 ` Rasmus
2015-03-03 9:39 ` Rasmus
2015-03-03 14:12 ` Aaron Ecay
2015-03-02 18:50 ` Richard Lawrence
2015-03-02 20:14 ` Nicolas Goaziou
2015-03-02 20:34 ` Rasmus
2015-03-02 22:17 ` Nicolas Goaziou
2015-03-02 22:33 ` Rasmus
2015-03-02 22:45 ` Nicolas Goaziou
2015-03-02 23:05 ` Rasmus
2015-03-02 23:27 ` Nicolas Goaziou
2015-03-02 23:42 ` Rasmus
2015-03-03 2:48 ` Richard Lawrence
2015-03-03 8:43 ` Nicolas Goaziou
2015-03-03 16:59 ` Richard Lawrence
2015-03-04 0:43 ` Matt Price
2015-03-08 0:16 ` Nicolas Goaziou
2015-03-03 14:23 ` Aaron Ecay
2015-03-02 18:54 ` Aaron Ecay
2015-03-02 20:26 ` Nicolas Goaziou
2015-03-03 2:53 ` Richard Lawrence
2015-03-03 8:38 ` Nicolas Goaziou
2015-03-03 9:13 ` Rasmus
2015-03-03 16:12 ` Richard Lawrence
2015-03-03 14:25 ` Aaron Ecay
2015-03-02 20:53 ` Rasmus
2015-03-03 14:57 ` Aaron Ecay
2015-03-03 15:41 ` Rasmus
2015-03-03 15:58 ` Ken Mankoff
2015-03-03 16:08 ` Rasmus
2015-03-03 17:13 ` Richard Lawrence
2015-03-10 3:44 ` Aaron Ecay
2015-03-10 9:49 ` Rasmus
2015-03-11 1:51 ` Aaron Ecay
2015-03-11 6:04 ` Thomas S. Dye
2015-03-10 16:31 ` Richard Lawrence
2015-03-11 2:21 ` Aaron Ecay
2015-03-11 17:33 ` Richard Lawrence
2015-03-13 18:13 ` Richard Lawrence
2015-03-17 5:15 ` Richard Lawrence
2015-03-17 9:27 ` Andreas Leha
2015-03-17 16:26 ` Richard Lawrence
2015-03-17 20:42 ` Andreas Leha
2015-03-17 21:34 ` Richard Lawrence
2015-03-18 1:12 ` Matt Price
2015-03-18 15:19 ` Richard Lawrence
2015-02-25 18:08 ` Thomas S. Dye
2015-02-26 21:30 ` Aaron Ecay
2015-02-26 23:50 ` Thomas S. Dye
2015-02-27 8:49 ` Stefan Nobis
2015-02-27 16:35 ` Richard Lawrence
2015-02-27 10:09 ` Rasmus
2015-03-02 5:48 ` Thomas S. Dye
2015-03-02 12:22 ` Aaron Ecay
2015-03-02 13:53 ` Thomas S. Dye
2015-03-02 19:02 ` Aaron Ecay
2015-02-20 5:27 ` Melanie Bacou
2015-02-20 16:49 ` Richard Lawrence
2015-02-24 7:08 ` Vaidheeswaran C
2015-02-25 4:29 ` Richard Lawrence
2015-02-25 5:57 ` Vaidheeswaran C
2015-02-15 11:17 ` Tory S. Anderson
2015-02-15 11:57 ` Rasmus
2015-02-15 17:05 ` Richard Lawrence
2015-02-16 8:53 ` Stefan Nobis
2015-02-16 17:52 ` Thomas S. Dye
2015-02-15 17:23 ` Nicolas Goaziou
2015-03-09 10:40 ` Sebastien Vauban
2015-03-09 10:50 ` Vaidheeswaran C
2015-02-15 17:19 ` Nicolas Goaziou
2015-02-15 17:37 ` Rasmus
2015-02-15 17:55 ` Nicolas Goaziou
2015-02-15 19:30 ` John Kitchin
2015-02-15 18:07 ` Richard Lawrence [this message]
2015-02-15 18:25 ` Nicolas Goaziou
2015-02-15 19:05 ` Aaron Ecay
2015-02-15 19:18 ` Nicolas Goaziou
2015-02-15 19:38 ` Aaron Ecay
2015-02-15 20:13 ` Nicolas Goaziou
2015-02-15 20:23 ` Rasmus
2015-02-16 9:07 ` Stefan Nobis
2015-02-16 16:59 ` Richard Lawrence
2015-02-16 17:43 ` Nicolas Goaziou
2015-02-16 18:39 ` Rasmus
2015-02-16 19:16 ` Thomas S. Dye
2015-02-16 19:40 ` Rasmus
2015-02-15 20:49 ` John Kitchin
2015-02-16 16:18 ` Richard Lawrence
2015-02-16 18:21 ` John Kitchin
2015-02-16 12:05 ` Eric S Fraga
2015-02-16 13:10 ` William Denton
2015-02-16 13:42 ` John Kitchin
2015-02-16 16:19 ` Nicolas Goaziou
2015-02-16 17:28 ` John Kitchin
2015-02-16 18:49 ` Rasmus
2015-02-16 19:16 ` John Kitchin
2015-02-23 7:26 ` Vaidheeswaran
2015-02-16 16:35 ` Jorge A. Alfaro-Murillo
2015-02-16 17:56 ` Stefan Nobis
2015-02-16 18:24 ` John Kitchin
2015-02-16 18:39 ` Jorge A. Alfaro-Murillo
2015-02-16 19:19 ` Jorge A. Alfaro-Murillo
2015-02-17 6:47 ` Stefan Nobis
2015-02-16 16:45 ` 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=873867m4kg.fsf@berkeley.edu \
--to=richard.lawrence@berkeley.edu \
--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).