Hi Johan,

Thanks for raising this issue.

2014ko abenudak 10an, "Johan W. Klüwer"-ek idatzi zuen:
> 
> I encountered a problem with unmatched double quotes in an org-babel
> table of results. Seems like the issue lies with escaped double quotes:
> 
>   (org-babel-script-escape "[[\"a\", \"b\\\"\"]]")
> 
>   returns error >  Invalid read syntax: "] in a list".
> 
> Adding the following after line 41 of org-babel-script-escape appears to
> fix the problem.
> 
>   (92 (if in-single ; \
>          (append (list 92 34 out))
>       (setq in-double (not in-double)) (cons 92 out)))
> 
> We now get
> 
>   (org-babel-script-escape "[[\"a\", \"b\\\"\"]]")
>   (("a" "b\""))

Unfortunately, while your suggested modification does correct the
issue in your case, it is not a very general fix.  As you noted, the
org-babel-script-escape function did not take account of backslash
escapes; it had other issues as well.  Attached is a proposed patch
which (tries to) improve the situation, including adding a test for
this function.

(There are also two clean-up patches attached.)

Unfortunately these functions try to interpret the list and string
formats of many different programming languages.  So there will always
be corner cases.  (One obvious one that exists now is: should \n escape
sequences be turned into newline characters?)

In the long run, I’d be tempted to say that babel should only provide
functions to convert JSON, CSV (and perhaps a few other widely-used
formats) to lisp (piggybacking off of existing libraries, when
available).  Org-babel-script-escape could be kept but marked
deprecated, in order to encourage babel languages to either use one of
the common formats or do any needed processing themselves in a
guaranteed-proper way.

Comments are welcome.