From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [PATCH] Process hlines in imported tables Date: Sat, 06 Apr 2013 10:29:33 -0600 Message-ID: <87zjxbfwr6.fsf@gmail.com> References: <20130329014615.GA49671@BigDog.local> <87wqsq6yd1.fsf@gmail.com> <20130329214238.GA53401@BigDog.local> <87r4ixah7y.fsf@gmail.com> <20130330234151.GA53721@BigDog.local> <87mwtkqtzh.fsf@gmail.com> <20130331122900.GA57939@BigDog.local> <87vc83bhma.fsf@Rainer.invalid> <867gkiz99z.fsf@somewhere.org> <878v4y857m.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([208.118.235.92]:54376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOW0E-0008Ph-Go for emacs-orgmode@gnu.org; Sat, 06 Apr 2013 12:30:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UOW0B-0003jR-Hi for emacs-orgmode@gnu.org; Sat, 06 Apr 2013 12:30:06 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:59190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOW0B-0003gH-4T for emacs-orgmode@gnu.org; Sat, 06 Apr 2013 12:30:03 -0400 Received: by mail-pa0-f41.google.com with SMTP id kx1so2552246pab.28 for ; Sat, 06 Apr 2013 09:30:02 -0700 (PDT) In-Reply-To: <878v4y857m.fsf@Rainer.invalid> (Achim Gratz's message of "Thu, 04 Apr 2013 21:29:33 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Achim Gratz Cc: emacs-orgmode@gnu.org --=-=-= Content-Type: text/plain Achim Gratz 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. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-raw-org-and-drawer-imply-verbatim-results.patch >From c12003708f691862086aac30c675868cd69d6bb3 Mon Sep 17 00:00:00 2001 From: Eric Schulte 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 --=-=-= Content-Type: text/plain > 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 --=-=-=--