From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: Citation syntax: a revised proposal Date: Fri, 20 Feb 2015 15:33:59 -0700 Message-ID: References: <87k2zjnc0e.fsf@berkeley.edu> <87bnkvm8la.fsf@berkeley.edu> <87zj8co3se.fsf@berkeley.edu> <87ioezooi2.fsf@berkeley.edu> <87mw4bpaiu.fsf@nicolasgoaziou.fr> <8761aznpiq.fsf@berkeley.edu> <87twyjnh0r.fsf@nicolasgoaziou.fr> <87oaopx24e.fsf@berkeley.edu> <87k2zd4f3w.fsf@nicolasgoaziou.fr> <87egpkv8g9.fsf@berkeley.edu> <87a908qrmm.fsf@gmx.us> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOw94-0001Ua-BJ for emacs-orgmode@gnu.org; Fri, 20 Feb 2015 17:34:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YOw93-00026j-4Y for emacs-orgmode@gnu.org; Fri, 20 Feb 2015 17:34:02 -0500 Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:41176) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YOw92-00026R-Sh for emacs-orgmode@gnu.org; Fri, 20 Feb 2015 17:34:01 -0500 Received: by labpv20 with SMTP id pv20so8979022lab.8 for ; Fri, 20 Feb 2015 14:34:00 -0800 (PST) In-Reply-To: <87a908qrmm.fsf@gmx.us> 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: Rasmus Cc: emacs-orgmode@gnu.org hi rasmus, On 2/20/15, Rasmus wrote: > I think everybody is thinking along the lines, but some people want to no= t > have another link-morass :) In particular, I think we are trying hard to > avoid this situation: > > i just think the syntax we design should, if possible, be so general > that it can be used for future features, *including 100% unrelated > features*, and also for future subfeatures of any feature, including > citations. this means that we are not thinking along the same lines. what i am describing is what i described years ago in several posts. it was mentioned recently [and on john's blog], then discussion went back to citation-specific syntax. > These days, my impression is that Org developers like to have [fn:=C2=B7] > always be of a footnote type and *bold* always be of bold type. i am not proposing hijacking existing syntax; i am proposing the opposite. i am proposing a single, new, unambiguous syntax. e.g. $[feature args... :key value ...] for more than just "the feature we need today". i don't care about the details of the outer syntax. and i misspoke when i said plist. i meant specifiable via a lambda list. for today's feature, that can mean e.g. $[cite blah :blah2 blah3] if you want to keep the mnemonic, that's fine too: $[(Cite) blah ...] but suppose we want, oh, say, backend-independent color in 5 years: $[color-start "red"]red$[color-end "red"] [i am just making this up as i go along to give you the general idea.] notice how we did not need to invent new syntax! >> to me, that means plist or similar. > > A lambda (that is a cite-subtype) is =E2=88=9E more customizable than a p= list. i don't think i'd favor anything that must eval. security issues, among other things. > A generalization of, say macros and link which look like [FUN: :key value= ] > or [FUN: arg]{:key value} may be appropriate, but it's something > different from the discussion at hand. i'm not sure i am explaining my point well here. samuel --=20 The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.