[O] Re: [Orgmode] Re: org-babel-read should have option NOT to interpret as elisp

[Eric Schulte]

Vladimir Alexiev <address@hidden> 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.