From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: emacs-orgmode@gnu.org
Subject: Re: Citations, continued
Date: Mon, 02 Feb 2015 08:58:54 -0800 [thread overview]
Message-ID: <871tm8mer5.fsf@berkeley.edu> (raw)
In-Reply-To: m2fvaoc49h.fsf@tsdye.com
tsd@tsdye.com (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
next prev parent reply other threads:[~2015-02-02 16:59 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 [this message]
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
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=871tm8mer5.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).