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

2011-03-02 Thread Eric Schulte
Vladimir Alexiev vladi...@sirma.bg 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

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

2011-03-01 Thread Vladimir Alexiev
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 it

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

2011-03-01 Thread Eric Schulte
Vladimir Alexiev vladi...@sirma.bg 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

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

2011-03-01 Thread Vladimir Alexiev
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 the

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

2011-02-28 Thread Sébastien Vauban
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

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

2011-02-28 Thread Eric Schulte
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

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

2011-02-28 Thread Eric Schulte
Vladimir Alexiev vladi...@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

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

2011-02-27 Thread Vladimir Alexiev
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 I

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

2011-02-27 Thread Eric Schulte
Vladimir Alexiev vladi...@sirma.bg 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

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

2011-02-27 Thread Vladimir Alexiev
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