emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric Schulte <schulte.eric@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Process hlines in imported tables
Date: Sun, 31 Mar 2013 07:37:38 -0600	[thread overview]
Message-ID: <87ip47r8pp.fsf@gmail.com> (raw)
In-Reply-To: <20130331122900.GA57939@BigDog.local> (Rick Frankel's message of "Sun, 31 Mar 2013 08:29:00 -0400")

Rick Frankel <rick@rickster.com> writes:

> On Sat, Mar 30, 2013 at 06:43:30PM -0600, Eric Schulte wrote:
>> Rick Frankel <rick@rickster.com> 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	other threads:[~2013-03-31 13:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-29  1:46 [PATCH] Process hlines in imported tables Rick Frankel
2013-03-29 15:04 ` Eric Schulte
2013-03-29 21:42   ` Rick Frankel
2013-03-30  0:01     ` Eric Schulte
2013-03-30 23:41       ` Rick Frankel
2013-03-31  0:43         ` Eric Schulte
2013-03-31 12:29           ` Rick Frankel
2013-03-31 13:37             ` Eric Schulte [this message]
2013-04-01 16:22               ` babel results handling (was: Process hlines in imported tables) Rick Frankel
2013-04-03 14:18                 ` babel results handling Eric Schulte
2013-04-03 18:02                   ` Achim Gratz
2013-04-04 18:20                   ` Rick Frankel
2013-04-03 18:21             ` [PATCH] Process hlines in imported tables Achim Gratz
2013-04-04 13:59               ` Sebastien Vauban
2013-04-04 15:02                 ` Eric Schulte
2013-04-04 21:01                   ` Sebastien Vauban
2013-04-06 16:30                     ` Eric Schulte
2013-04-15 13:06                     ` Sebastien Vauban
2013-04-15 15:25                       ` Eric Schulte
2013-04-15 19:27                         ` Sebastien Vauban
2013-04-04 18:35                 ` Rick Frankel
2013-04-04 21:05                   ` Sebastien Vauban
2013-04-04 19:29                 ` Achim Gratz
2013-04-06 16:29                   ` Eric Schulte
2013-04-06 17:07                     ` Eric Schulte
2013-04-06 17:24                     ` Bastien
2013-04-06 17:39                       ` Eric Schulte
2013-04-04 18:30               ` Rick Frankel
2013-04-04 20:27                 ` Sebastien Vauban

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ip47r8pp.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).