[PATCH] Strip text properties from string code block arguments

[PATCH] Strip text properties from string code block arguments

[Daniel Gerber]

Hi,

This change in org-babel-python-var-to-python makes python code blocks 
accept a string with text properties (as one gets when referring another 
code block). I guess there should be something similar for other languages.

diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 1457682..baa5764 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -137,7 +137,7 @@ specifying a variable of the same value."
         org-babel-python-hline-to
        (format
         (if (and (stringp var) (string-match "[\n\r]" var)) 
"\"\"%S\"\"" "%S")
-       var))))
+       (if (stringp var) (substring-no-properties var) var)))))

  (defun org-babel-python-table-or-string (results)
    "Convert RESULTS into an appropriate elisp value.

Re: [PATCH] Strip text properties from string code block arguments

[Bastien]

Hi Daniel,

Daniel Gerber <daniel.g.gerber@gmail.com> writes:

> This change in org-babel-python-var-to-python makes python code blocks
> accept a string with text properties (as one gets when referring
> another code block). I guess there should be something similar for
> other languages.

I don't understand why properties would be a problem here.
Can you elaborate a bit on this?

Thanks,

-- 
 Bastien

Re: [PATCH] Strip text properties from string code block arguments

[Achim Gratz]

Bastien writes:
> I don't understand why properties would be a problem here.
> Can you elaborate a bit on this?

With format "%S" prints an s-expression via prin1, not a string.  So
either the format should be "%s" or the properties need to be stripped
unless one really wants to interpret the result via read again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [PATCH] Strip text properties from string code block arguments

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> I don't understand why properties would be a problem here.
>> Can you elaborate a bit on this?
>
> With format "%S" prints an s-expression via prin1, not a string.  So
> either the format should be "%s" or the properties need to be stripped
> unless one really wants to interpret the result via read again.

I think this is a simple typo and s/%S/%s would do.

I'll have a closer look and fix this later today.

-- 
 Bastien

Re: [PATCH] Strip text properties from string code block arguments

[Daniel Gerber]

Hi Bastien,

On 07/01/2014 18:31, Bastien wrote:
> Daniel Gerber<daniel.g.gerber@gmail.com>  writes:
>
>> This change in org-babel-python-var-to-python makes python code blocks
>> accept a string with text properties (as one gets when referring
>> another code block). I guess there should be something similar for
>> other languages.
> I don't understand why properties would be a problem here.
> Can you elaborate a bit on this?
The problem is that formatting as s-expression puts them into python code.

Here is what I want to do.

First edit a query string:
#+RESULTS: query
#+BEGIN_SRC sparql
   select *
   where { ?x rdf:label "x\\r"@en }
#+END_SRC

(The trick of naming this block with #+results: is so that:
   1. org-edit-src-code uses the right mode
   2. the code block is not evaluated
   3. its body is passed as a string to other code blocks.
For lack of a better idea...)

Use the query string verbatim in another language:
#+NAME: py
#+BEGIN_SRC python :var q=query
   # return some_graph.query(q)
   return q
#+END_SRC

But now calling py() or tangling would give a syntax error because
#+BEGIN_SRC elisp :var q=query
   (org-babel-python-var-to-python q)
#+END_SRC

#+RESULTS:
: ""#("select *
: where { ?x rdf:label \"x\\\\r\"@en }
: " 0 9 (face org-block font-lock-multiline t wrap-prefix #("  " 0 2 
(face org-indent)) line-prefix nil font-lock-fontified t fontified t) 9 
30 (face org-block font-lock-multiline t wrap-prefix #("  " 0 2 (face 
org-indent)) line-prefix nil font-lock-fontified t fontified t) 30 35 
(face org-block font-lock-multiline t font-lock-fontified t wrap-prefix 
#("  " 0 2 (face org-indent)) line-prefix nil fontified t) 35 40 (face 
org-block font-lock-multiline t font-lock-fontified t wrap-prefix #("  " 
0 2 (face org-indent)) line-prefix nil fontified t) 40 41 (face 
org-block font-lock-multiline t wrap-prefix #("  " 0 2 (face 
org-indent)) line-prefix nil font-lock-fontified t fontified t) 41 42 
(face org-block font-lock-multiline t wrap-prefix #("  " 0 2 (face 
org-indent)) line-prefix nil font-lock-fontified t fontified t))""

If org-babel-python-var-to-python does
#+BEGIN_SRC elisp :var q=query
   (format "%S" (substring-no-properties q))
#+END_SRC

#+RESULTS:
: "select *
: where { ?x rdf:label \"x\\\\r\"@en }
: "

then both evaluation and tangling work fine:
#+CALL: py()

#+RESULTS:
: select *
:     where { ?x rdf:label "x\\r"@en }


Best,
Daniel

Re: [PATCH] Strip text properties from string code block arguments

[Bastien]

Daniel Gerber <daniel.g.gerber@gmail.com> writes:

> This change in org-babel-python-var-to-python makes python code blocks
> accept a string with text properties (as one gets when referring
> another code block). I guess there should be something similar for
> other languages.

I've now fixed this by using %s instead of %S, let me know if this
works correctly for you.

-- 
 Bastien

Re: [PATCH] Strip text properties from string code block arguments

[Daniel Gerber]

On 08/01/2014 17:31, Bastien wrote:
> Daniel Gerber <daniel.g.gerber@gmail.com> writes:
>
>> This change in org-babel-python-var-to-python makes python code blocks
>> accept a string with text properties (as one gets when referring
>> another code block). I guess there should be something similar for
>> other languages.
> I've now fixed this by using %s instead of %S, let me know if this
> works correctly for you.
Not quite. I thought %S was not a typo because it escapes characters 
more nicely. E.g. with %s the buffer should contain \"\"\" to mean """ 
in python.

Also, one quote is missing
-       (if (and (stringp var) (string-match "[\n\r]" var)) "\"\"%s\"\"" 
"%s")
+       (if (and (stringp var) (string-match "[\n\r]" var)) 
"\"\"\"%s\"\"\"" "\"%s\"")

Re: [PATCH] Strip text properties from string code block arguments

[Bastien]

Daniel Gerber <daniel.g.gerber@gmail.com> writes:

> On 08/01/2014 17:31, Bastien wrote:
>> Daniel Gerber <daniel.g.gerber@gmail.com> writes:
>>
>>> This change in org-babel-python-var-to-python makes python code blocks
>>> accept a string with text properties (as one gets when referring
>>> another code block). I guess there should be something similar for
>>> other languages.
>> I've now fixed this by using %s instead of %S, let me know if this
>> works correctly for you.
> Not quite. I thought %S was not a typo because it escapes characters
> more nicely. E.g. with %s the buffer should contain \"\"\" to mean """
> in python.

I reverted my change -- can you resubmit a proper patch,
i.e. one with an Emacs changelog and using git format-patch?

Thanks!

-- 
 Bastien

Re: [PATCH] Strip text properties from string code block arguments

[Achim Gratz]

Daniel Gerber writes:
> Not quite. I thought %S was not a typo because it escapes characters
> more nicely. E.g. with %s the buffer should contain \"\"\" to mean """
> in python.

If that's the intention, then %S is arguably a latent bug, since the
escaping it applies can only by accident be compatible with the targeted
language.  I don't know if something like shell-quote arguments exists
for arbitrary programming languages.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [PATCH] Strip text properties from string code block arguments

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> Daniel Gerber writes:
>> Not quite. I thought %S was not a typo because it escapes characters
>> more nicely. E.g. with %s the buffer should contain \"\"\" to mean """
>> in python.
>
> If that's the intention, then %S is arguably a latent bug, since the
> escaping it applies can only by accident be compatible with the targeted
> language.  I don't know if something like shell-quote arguments exists
> for arbitrary programming languages.

Maybe we should simply use %s (downcase) and escape quotes manually.
If feels less random to me.

What do you think?

-- 
 Bastien

Re: [PATCH] Strip text properties from string code block arguments

[Eric Schulte]

Bastien <bzg@gnu.org> writes:

> Achim Gratz <Stromeko@nexgo.de> writes:
>
>> Daniel Gerber writes:
>>> Not quite. I thought %S was not a typo because it escapes characters
>>> more nicely. E.g. with %s the buffer should contain \"\"\" to mean """
>>> in python.
>>
>> If that's the intention, then %S is arguably a latent bug, since the
>> escaping it applies can only by accident be compatible with the targeted
>> language.  I don't know if something like shell-quote arguments exists
>> for arbitrary programming languages.
>
> Maybe we should simply use %s (downcase) and escape quotes manually.
> If feels less random to me.
>
> What do you think?

I think using %S with strip-properties will address the great majority
of cases, and is certainly a better interim solution than the current
use of %s with no escaping.  I find string escaping is *normally* very
consistent between languages.

Then if someone wants to read the python spec, and implement custom
string escaping that would be useful, but it isn't immediately required.

Alternately maybe python's long-form """ strings should be used in all
cases?

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: [PATCH] Strip text properties from string code block arguments

[Bastien]

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> I think using %S with strip-properties will address the great majority
> of cases, and is certainly a better interim solution than the current
> use of %s with no escaping.  I find string escaping is *normally* very
> consistent between languages.

Okay, that's now the case in maint.

> Then if someone wants to read the python spec, and implement custom
> string escaping that would be useful, but it isn't immediately required.

Indeed.

-- 
 Bastien