Re: [O] [PATCH] Process hlines in imported tables

[Eric Schulte]

Achim Gratz <address@hidden> writes:

> Sebastien Vauban writes:
>> Achim Gratz wrote:
>>> Elisp is different from all other languages: it doesn't do any
>>> processing of strings to begin with for value returns.  The reason that
>>> Perl processes "raw" results is that org-babel-result-cond does not
>>> switch to the "scalar" path for this condition, which is why you need
>>> the extra "verbatim".  It probably should, though, so if Eric agrees
>>> then I will push a change that does this.
>>
>> IIUC, wouldn't that be changing the default answer to "how to
>> interpret the results" just for Perl?  While the default answer for
>> all languages seems to be "table"?
>
> Again, org-babel-result-cond doesn't interpret "raw" at all at the
> moment, which I think is a bug.  This leads to the interpretation of
> multiline strings and strings with separators in the return value as
> tables.

The attached patch updates the org-babel-result-cond macro so that
"raw", "org" and "drawer" all imply verbatim results *unless* the
":results table" header argument is explicitly specified.  I think this
is an improvement and should (hopefully) be merged before the 8.0
release.  Could everyone on this thread test this patch and let me know
what you think before I apply it?  I'm nervous about such a patch at the
last minute.

>From c12003708f691862086aac30c675868cd69d6bb3 Mon Sep 17 00:00:00 2001
From: Eric Schulte <address@hidden>
Date: Sat, 6 Apr 2013 10:18:35 -0600
Subject: [PATCH] raw org and drawer imply verbatim results

  This unifies the results handling across a number of different
  languages.  It is still possible to force tabular output by adding the
  ":results table" argument.

The following example demonstrates the results in shell python and perl.

** drawer and table
#+begin_src sh :results drawer table
 echo -e "1\n2\n3"
#+end_src

#+RESULTS:
:RESULTS:
| 1 |
| 2 |
| 3 |
:END:

#+begin_src perl :results drawer table
"1\n2\n3"
#+end_src

#+RESULTS:
:RESULTS:
| 1 |
| 2 |
| 3 |
:END:

#+begin_src python :results drawer table
return "1\n2\n3"
#+end_src

#+RESULTS:
:RESULTS:
| 1\n2\n3 |
:END:

** drawer
#+begin_src sh :results drawer
 echo -e "1\n2\n3"
#+end_src

#+RESULTS:
:RESULTS:
1
2
3
:END:

#+begin_src perl :results drawer
"1\n2\n3"
#+end_src

#+RESULTS:
:RESULTS:
1
2
3
:END:

#+begin_src python :results drawer
return "1\n2\n3"
#+end_src

#+RESULTS:
:RESULTS:
1
2
3
:END:

** raw
#+begin_src sh :results raw
 echo -e "1\n2\n3"
#+end_src

#+RESULTS:
1
2
3

#+begin_src perl :results raw
"1\n2\n3"
#+end_src

#+RESULTS:
1
2
3

#+begin_src python :results raw
return "1\n2\n3"
#+end_src

#+RESULTS:
1
2
3

* lisp/ob-core.el (org-babel-result-cond): The "raw", "org" and "drawer"
  :results header argument values preclude table processing unless the
  "table" argument is given as well.
---
 lisp/ob-core.el | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index bba2dfe..b8f863f 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2637,10 +2637,14 @@ Emacs shutdown."))
             (member "html" ,result-params)
             (member "code" ,result-params)
             (member "pp" ,result-params)
-            (and (member "output" ,result-params)
+            (and (or (member "output" ,result-params)
+                     (member "raw"    ,result-params)
+                     (member "org"    ,result-params)
+                     (member "drawer" ,result-params))
                  (not (member "table" ,result-params))))
         ,scalar-form
        ,@table-forms)))
+(def-edebug-spec org-babel-result-cond (form form body))
 
 (defun org-babel-temp-file (prefix &optional suffix)
   "Create a temporary file in the `org-babel-temporary-directory'.
-- 
1.8.2

> Not all Babel languages are using that macro, so these implementations
> might have a different interpretation (which may or may not be a bug
> in itself).
>

Every general purpose language should be using this macro.  The
following lists those ob*.el files which don't use this macro.

    $ grep -rc org-babel-result-cond lisp/ob*el|grep 0|sed 's/:.*$//'
    lisp/ob-asymptote.el
    lisp/ob-calc.el
    lisp/ob-comint.el
    lisp/ob-css.el
    lisp/ob-ditaa.el
    lisp/ob-dot.el
    lisp/ob.el
    lisp/ob-eval.el
    lisp/ob-exp.el
    lisp/ob-gnuplot.el
    lisp/ob-haskell.el
    lisp/ob-js.el
    lisp/ob-keys.el
    lisp/ob-latex.el
    lisp/ob-ledger.el
    lisp/ob-lilypond.el
    lisp/ob-lob.el
    lisp/ob-makefile.el
    lisp/ob-matlab.el
    lisp/ob-mscgen.el
    lisp/ob-ocaml.el
    lisp/ob-octave.el
    lisp/ob-org.el
    lisp/ob-plantuml.el
    lisp/ob-ref.el
    lisp/ob-ruby.el
    lisp/ob-sass.el
    lisp/ob-scheme.el
    lisp/ob-screen.el
    lisp/ob-table.el
    lisp/ob-tangle.el

Of these I would guess that the following 7 should be updated to use the
org-babel-result-cond macro.

  scheme ruby ocaml matlab js haskell asymptote

I don't know if we want to try to make these changes before the 8.0
release.  I personally could update and test js, scheme, ocaml and
haskell this weekend.  I do not have ruby, matlab or asymptote installed
on my laptop.

Thanks,

>
>
> Regards,
> Achim.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte