emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Schulte
Subject: Re: [O] [PATCH] Process hlines in imported tables
Date: Sun, 31 Mar 2013 07:37:38 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Rick Frankel <address@hidden> writes:

> On Sat, Mar 30, 2013 at 06:43:30PM -0600, Eric Schulte wrote:
>> Rick Frankel <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]