emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] Citations, continued


From: Richard Lawrence
Subject: Re: [O] Citations, continued
Date: Mon, 02 Feb 2015 08:58:54 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

address@hidden (Thomas S. Dye) writes:

> You and others are advocating a separate syntax for links and citations,
> which might indeed be the way to go.  I can see it being much nicer than
> the current state of affairs with Org mode links.  The downside is that
> it will mean learning another set of rules, in addition to the existing
> rules for links.

Yes, I agree, and I see the import of this concern.  Links and citations
have enough similarities that some more generalized syntax could
probably cover them both, as you suggest below.

The main upside, as I see it, of adopting a totally different syntax for
citations is that we have the option to adopt a syntax that is already
known to be good enough (for some set of uses) and to work with other
tools (like Pandoc).  But this is a `merely practical' concern and maybe
does not outweight the considerations above.

> Several years ago, Samuel Wales suggested an extensible syntax example
> using link features
> (https://lists.gnu.org/archive/html/emacs-orgmode/2010-08/msg00404.html).
> At the time it seemed to me that this was a Lisp-y approach because it
> solved particular problems by generalizing or abstracting a language
> feature to include particulars that had previously fallen outside its
> ken.  I wanted something like this while I was working on implementing
> citation links for export to LaTeX.
>
> Would it be feasible to generalize Org mode's link syntax, or make it
> extensible, so the overlap of link with citation is complete?  

This is an interesting idea!

I think the minimal change that would be necessary would be to allow the
new extended links (call them `elinks' for short) to be defined in such
a way that they can have varying numbers of significant parts, depending
on the type.  An elink definition for a given type would specify a
number and order of parts.  All elinks would use the same syntax to
delimit the parts.  To keep things simple and more or less consistent
with the existing syntax, we could just surround each part with square
brackets, and assume that only the first part is required.

Thus, the relevant definitions could look like:

href: URL DESCRIPTION
cite: KEY PRE-TEXT POST-TEXT 

with examples like:

[href: [http://www.google.com]]
[href: [http://www.google.com][Evil search engine]]

[cite: [Smith99]]
[cite: [Smith99][Cf.]]
[cite: [Smith99][Cf.][for a discussion]]

though this doesn't quite solve the readability problem with having
optional pre and post text appear after the key.

In theory, this syntax could even allow complicated nestings:

multi-cite: CITE-ELINK ...

[multi-cite: [cite: [Smith99]]
             [cite: [Doe2000]]
             [cite: [Foobar2014][a summary appears in]]
             [cite: [Baz2014][][which is available at [href: [http://baz.org]]]]

though that might quickly get unwieldy (especially for non-Lispers). :)

Link handlers would become functions that accept one argument plus a
&rest list, and the choice of link handler would dispatch on the type.

An alternative to the brackets would be to use something like plist
syntax for the optional arguments (as Samuel originally suggested and
Rasmus has echoed).  Links would really just start to look like Lisp
function calls. 

I'm just spitballing here; not sure I'd ultimately endorse something
like this, but I think it's worthwhile to explore the question of how
link and citation syntax could usefully be generalized.

Best,
Richard




reply via email to

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