[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Orgmode] Re: org-babel-read should have option NOT to interpret as elis
From: |
Vladimir Alexiev |
Subject: |
[Orgmode] Re: org-babel-read should have option NOT to interpret as elisp |
Date: |
Mon, 28 Feb 2011 00:30:38 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
> 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
- 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)
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.
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.