From: "Eric Schulte" <schulte.eric@gmail.com>
To: Vladimir Alexiev <vladimir@sirma.bg>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: org-babel-read should have option NOT to interpret as elisp
Date: Mon, 28 Feb 2011 20:11:26 -0700 [thread overview]
Message-ID: <87vd037c4r.fsf@gmail.com> (raw)
In-Reply-To: loom.20110228T005121-911@post.gmane.org
Vladimir Alexiev <vladimir@sirma.bg> 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.
next prev parent reply other threads:[~2011-03-01 3:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-27 14:14 org-babel-read should have option NOT to interpret as elisp Vladimir Alexiev
2011-02-27 15:51 ` Eric Schulte
2011-02-27 23:28 ` Vladimir Alexiev
2011-02-27 23:44 ` Eric Schulte
2011-02-28 0:30 ` Vladimir Alexiev
2011-03-01 3:11 ` Eric Schulte [this message]
2011-03-01 12:19 ` Vladimir Alexiev
2011-03-01 16:58 ` Eric Schulte
2011-03-02 7:20 ` Vladimir Alexiev
2011-03-02 14:56 ` Eric Schulte
2011-02-28 10:07 ` Sébastien Vauban
2011-03-01 3:10 ` Eric Schulte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vd037c4r.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=vladimir@sirma.bg \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).