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: Fri, 27 Feb 2015 08:35:03 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Hi Stefan,

Stefan Nobis <address@hidden> writes:

> Aaron Ecay <address@hidden> writes:
>
>> I count roughly 50 commands in sections 3.7.1 – 3.7.6 of the
>> biblatex user’s manual (version 2.9a of 24/06/2014). Some of these
>> are quite esoteric, of course, but they are all provided.
>
> There are many commands (and even more private commands are possible)
> in order to help reproducing all the various citation styles out there.
>
> The critical question for org and org users is: How many different
> citation commands are needed in a single document (or needed by a
> single author within all her documents)?

These are very different questions.  I think we need to answer the
second, since the syntax for citations will be common to all documents.

> If no single author ever needs more than about a dozen different
> commands (including variations like the genetive versions), the
> [cite:subcommand ...] syntax should suffice.

Yes, I don't disagree.  But how do we know that no single author ever
needs more than a dozen different types/commands, across all her
documents, now and in the future?  I for one do not feel comfortable
making this judgment a priori.  As Aaron said, it's an empirical
question.

>> By way of illustration, Biblatex (AFAICT) doesn’t provide a
>> possessive citation command, which was mentioned by someone in this
>> thread (or its predecessor) as a desideratum. I’d expect a savvy
>> latex user to put in their preamble:
>
>> \newcommand{\citeposs}[1]{\citeauthor{#1}’s (\citeyear{#1})}
>
> This is what the subcommand is for. An author may define "poss" as a
> subcommand and use [cite:poss ...]. Then all the nice gimmicks will
> still work.

If I understand correctly, Aaron and I have two worries about this
approach.  First, doing things this way potentially leads to a lot of
redundancy in the code you have to write when defining subtypes, which
is a maintenance hassle and an extra burden on users.  Second, it means
that an author who has to deal with a lot of `uncommon' commands has to
remember a lot of subtype names, which are likely to be very similar,
because they represent overlapping groups of options.

Look at, e.g., the commands required in BibLaTeX to support citing
multi-volume works.  There are 24(!) of them, because every one of them
is simply a multi-volume version of other combinations of options that
BibLaTeX supports (multi-cite or not? parenthetical or in-text?
footnoted or not? etc.).

For my part, if I were citing multi-volume works a lot, I would
appreciate being able to express all those options using orthogonal
distinctions.  Then I could just add

{... :volume 2 ...}

at the end of a citation that already expresses most of those options in
the [cite: ...] part of the syntax.  I would personally prefer *not* to
have to write

[cite/SUBTYPE: ...]

and remember which, among those 24 command types, I need to use (and
define) here.  

(Also, note that this syntax does not have a way to pass additional
arguments like the volume, so it *can't* say "cite volume 2", even if
with a subtype label it can say "cite this multi-volume work".  Citing a
volume in a multi-volume work seems like it might require some ugly
hacking on the subtypes approach, but I have no idea how often people
actually use such citations.)

On the other hand, Tom says that he prefers the latter way of working,
even if it requires a lot of subtypes.  This is because it makes the
subtype easy to find-and-replace when changing a document from one
citation style to another.  Also, it is simpler to write custom handlers
that dispatch just on the subtype, rather than on a plist of options.

So there are considerations on both sides.  In the end, I prefer the 

[cite: ...]{:key val ...}

syntax because:

  1) it supports both styles of working (subtypes can be represented
     like `:type fvolcites')
  2) it allows passing additional arguments (e.g., volume number)
  3) something like this is needed anyway elsewhere in Org

but I recognize there are some drawbacks to this over the simpler
approach of subtype labels.
  
Best,
Richard




reply via email to

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