From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: Citations, continued Date: Mon, 02 Feb 2015 08:58:54 -0800 Message-ID: <871tm8mer5.fsf@berkeley.edu> References: <87vbjmn6wy.fsf@berkeley.edu> <8761blm6n8.fsf@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIKLk-0004tb-01 for emacs-orgmode@gnu.org; Mon, 02 Feb 2015 11:59:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YIKLh-0006W5-8W for emacs-orgmode@gnu.org; Mon, 02 Feb 2015 11:59:47 -0500 Received: from plane.gmane.org ([80.91.229.3]:35009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YIKLh-0006Ve-1O for emacs-orgmode@gnu.org; Mon, 02 Feb 2015 11:59:45 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YIKLf-00064Y-DP for emacs-orgmode@gnu.org; Mon, 02 Feb 2015 17:59:43 +0100 Received: from c-67-169-117-151.hsd1.ca.comcast.net ([67.169.117.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Feb 2015 17:59:43 +0100 Received: from richard.lawrence by c-67-169-117-151.hsd1.ca.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Feb 2015 17:59:43 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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