From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [PATCH] Process hlines in imported tables Date: Sun, 31 Mar 2013 07:37:38 -0600 Message-ID: <87ip47r8pp.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:38839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMISK-0005Gz-1i for emacs-orgmode@gnu.org; Sun, 31 Mar 2013 09:38:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMISI-00052y-6Q for emacs-orgmode@gnu.org; Sun, 31 Mar 2013 09:37:55 -0400 Received: from mail-pd0-f171.google.com ([209.85.192.171]:49270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMISH-00051v-Sg for emacs-orgmode@gnu.org; Sun, 31 Mar 2013 09:37:54 -0400 Received: by mail-pd0-f171.google.com with SMTP id z10so845925pdj.2 for ; Sun, 31 Mar 2013 06:37:53 -0700 (PDT) In-Reply-To: <20130331122900.GA57939@BigDog.local> (Rick Frankel's message of "Sun, 31 Mar 2013 08:29:00 -0400") 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: emacs-orgmode@gnu.org Rick Frankel writes: > On Sat, Mar 30, 2013 at 06:43:30PM -0600, Eric Schulte wrote: >> Rick Frankel writes: > >> > *Note* =wrap= and =raw= give same results >> > #+begin_src perl :results raw >> > q[|c1|c2| >> > |- >> > |a|1| >> > |b|2|]; >> > #+end_src >> > >> > #+results: >> > | | c1 | c2 | >> > | | - | | >> > | | a | 1 | >> > | | b | 2 | >> > >> >> This is a problem in the results returned by ob-perl, not in the results >> insertion mechanism. Given what is actually being returned by that code >> block the results make sense. >> >> #+name: perl-example >> #+begin_src perl :results raw >> q[|c1|c2| >> |- >> |a|1| >> |b|2|]; >> #+end_src > >> If we add verbatim (which inhibits interpretation as a value, which can >> often result in a list or table result), then we get what I assume you >> expect. > >> #+name: perl-example >> #+begin_src perl :results verbatim raw >> q[|c1|c2| >> |- >> |a|1| >> |b|2|]; >> #+end_src >> >> #+RESULTS: perl-example >> | c1 | c2 | >> |----+----| >> | a | 1 | >> | b | 2 | >> > Missed verbatim. Thanks for the pointer, it works, but i think that > perl is double-processing returned values. If we do the same things in > elisp i get (my) expected results: > Yes, because Emacs Lisp is the language of Emacs, it's results aren't interpreted as are the results of every other language. This was an intentional design decision, and it gives extra flexibility when working with Emacs Lisp. > > #+begin_src elisp :results raw > "|c1|c2| > |- > |a|1| > |b|2|"; > #+end_src > > #+results: > | c1 | c2 | > |----+----| > | a | 1 | > | b | 2 | > > *NOTE* this will not properly clean-up the results, but keep inserting > more copies. Yes, this is why ":results drawer" exists. > > #+begin_src elisp :results raw verbatim "|c1|c2| > |- > |a|1| > |b|2|"; > #+end_src > > #+results: > "|c1|c2| > |- > |a|1| > |b|2|" > >> > #+begin_src perl :results raw output >> > print q[|c1|c2| >> > |- >> > |a|1| >> > |b|2| >> > ]; > > Yes, this was included to show the inconsistency between value and > output returns. BTW, "raw output" and "raw output verbatim" generate > the same results. > Yes, output collects the code block result from STDOUT. The strings collected from STDOUT are not treated as values, but rather as raw strings. This should be true across every language. > >> >> Footnotes: >> [1] http://orgmode.org/worg/org-contrib/babel/header-args.html > > I will take a look and see if i come up with anything else. Please do, I think this page could become a great resource. > In general, what I have found with babel processing is that there is > major inconsistency between the results processing in different > languages. It is certainly true that Emacs Lisp is treated differently than all other languages. There are also significant differences between languages, e.g., session evaluation doesn't make sense for some languages, and for other languages session evaluation is the only type of evaluation that does make sense. In addition to that, with over 40 supported languages [1], There undoubtedly are cases where we are doing a bad job of ensuring inter-languages consistency. If you can find concise examples which use demonstrate significant inconsistencies between languages, then we should be able to resolve those on a case by case basis. In general I think ob-sh is probably the most widely used code block language, and can be treated as the gold standard against which other languages should be compared. > Somehow, I would think that the same output (modulo sytnactic > diferences) should generate the same results regardless of language. > I agree, modulo what I said about emacs-lisp. Please submit specific reproducible examples and we can get to work fixing them. Thanks, > > rick Footnotes: [1] Specifically, from the current master branch. ob-asymptote.el ob-awk.el ob-calc.el ob-C.el ob-clojure.el ob-css.el ob-ditaa.el ob-dot.el ob-emacs-lisp.el ob-fortran.el ob-gnuplot.el ob-haskell.el ob-io.el ob-java.el ob-js.el ob-keys.el ob-latex.el ob-ledger.el ob-lilypond.el ob-lisp.el ob-makefile.el ob-matlab.el ob-maxima.el ob-mscgen.el ob-ocaml.el ob-octave.el ob-org.el ob-perl.el ob-picolisp.el ob-plantuml.el ob-python.el ob-R.el ob-ruby.el ob-sass.el ob-scala.el ob-scheme.el ob-screen.el ob-sh.el ob-shen.el ob-sql.el ob-sqlite.el ob-tangle.el -- Eric Schulte http://cs.unm.edu/~eschulte