"Vladimir Alexiev" writes:
>> I believe quoted strings are already handled, e.g.,
>> #+results:
>> : "(a b c)"
>
> They are not. This leaves the quotes as part of the string.
>
Alright, I've changed this behavior so that double-quoted strings are
read into variable values (removing the quotes).
> I believe quoted strings are already handled, e.g.,
> #+results:
> : "(a b c)"
They are not. This leaves the quotes as part of the string.
Please add a second usage to the description:
(this is useful for having leading/trailing whitespace in a string,
or having a leading ('` yet preventing th
"Vladimir Alexiev" writes:
>> I've applied the patch
>> attached to my previous email and unless there is a real push-back ...
>
> Could you add handling of quoted strings?
I believe quoted strings are already handled, e.g.,
#+results: elisp-looking-table
| 1 | (a b c) |
| 2 | "(a b c)" |
#+
> I've applied the patch
> attached to my previous email and unless there is a real push-back ...
Could you add handling of quoted strings?
And most importantly, document all of this in "(org)var".
Here is a merged dscription:
If a value starts with one of ('` it is read as an emacs lisp sexp.
If
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")
> "
Hi Seb,
earlier in this thread, I attached a patch which allows string results
in tables which look like elisp to be interpreted literally, e.g.,
#+results: elisp-looking-table
| 1 | (+ 1 1) |
| 2 | (+ 2 2) |
| 3 | (+ 3 3) |
#+begin_src perl :var data=elisp-looking-table[1,1]
$data
#+end_src
Hi Eric,
"Eric Schulte" wrote:
> However I do agree that this would be onerous to have to wrap every cell of
> a table in double quotes...
Aren't we forced to do so, right now? As in the following home-made example:
#+TITLE: Show differences between files
* Code
Assuming you have two dire
> 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
Vladimir Alexiev writes:
>> would be onerous to have to wrap every cell
>> of a table in double quotes...
>
> I tried doing this as a workaround, but it is not
> since the quotes are passed to perl, and that's not what I want
>
>> it would be a breaking change for
>> anyone who is currently rely
> would be onerous to have to wrap every cell
> of a table in double quotes...
I tried doing this as a workaround, but it is not
since the quotes are passed to perl, and that's not what I want
> it would be a breaking change for
> anyone who is currently relying on the ability
Right, that's why
10 matches
Mail list logo
