From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Re: org-babel-read should have option NOT to interpret as elisp Date: Mon, 28 Feb 2011 20:11:26 -0700 Message-ID: <87vd037c4r.fsf@gmail.com> References: <877hclbgxz.fsf@gmail.com> <87hbbpyrde.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=55991 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuGGC-0008Ok-UO for emacs-orgmode@gnu.org; Mon, 28 Feb 2011 22:28:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuGGB-0006Vp-RB for emacs-orgmode@gnu.org; Mon, 28 Feb 2011 22:28:28 -0500 Received: from mail-yi0-f41.google.com ([209.85.218.41]:43958) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PuGGB-0006VH-Nd for emacs-orgmode@gnu.org; Mon, 28 Feb 2011 22:28:27 -0500 Received: by mail-yi0-f41.google.com with SMTP id 2so2297836yib.0 for ; Mon, 28 Feb 2011 19:28:27 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Vladimir Alexiev Cc: emacs-orgmode@gnu.org Vladimir Alexiev writes: >> What syntax would you suggest to indicate that a variable is to be >> passed without the possibility of elisp evaluation > > I think this should be done with a header arg, > since they have very flexible setup scheme: > see (info "(org)Using header arguments") > "values of header arguments can be set in six different ways" > > - Ideally, the arg should be attached to > #+tblname: since it's a characteristic of the table itself This would be a good way to go, however there is currently no support for attaching header arguments to tables, so this is not viable---unless there are enough other motivating use cases for attaching header arguments to tables and results, in which case this could be revisited. > > - If attached to #+begin_src: then it will be dissociated from the > table, and all :var's of that line will be forced to use the same arg. > - But that's good enough since it can be set in various ways. For me > most useful: -- org-babel-default-header-args: global -- #+BABEL: per > file > > The header arg should be called :read-as (or >:var-read). Considerations: > - should be quite distinct so it can be used as a property name > - should use dash so it's analogous to no-expand > > Its values should be: > - literal: > If a value looks like a number, it's read as a number. > Else it's read as a literal string. > - elisp or nil (default): > If a value starts with one of ('` it's read as emacs lisp. > Else it's read as 'literal'. > - quoted: > If a value starts with " then it's read as a quoted string: > start and end quotes are stripped, and \" escaped quotes are unescaped > (this is useful for embedding leading/trailing whitespace in strings). > Else it's read as `literal'. > - quoted_elisp: combination of `quoted' and `elisp' > (I assume that using multiple values per arg is not supported) > There are currently a number of header arguments which allow multiple arguments, e.g., :results. > > This above is about data coming from tables, > since I haven't used the other two options (literal value and code block). > The chosen solution should work for those too. > The problem here is the same as in our other table indexing thread, namely it requires that some header arguments be parsed and their results available *before* the :var header arguments are parsed. I think that the only viable solution may involve adding something to the actual :var header argument, although I can't think of any obvious syntax there. I'm thinking that any of the above would introduce undue complexity to the header argument parsing. For the interim, I've applied the patch attached to my previous email and unless there is a real push-back from users who are embedding executable elisp code into tables and lists I think this solution is the best compromise between usability and simplicity. Thanks -- Eric > > Please note that org-babel-read says > "This is taken almost directly from `org-read-prop'." > so the chosen solution should be compatible with that. > But I can't find such function. > Yes, the patch attached to my previous email fixes this documentation string.