emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Citation syntax: a revised proposal


From: Richard Lawrence
Subject: Re: [O] Citation syntax: a revised proposal
Date: Sun, 15 Feb 2015 10:07:27 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Hi Nicolas,

Thanks for your comments.  A couple of replies follow.

Nicolas Goaziou <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]