From: Torsten Wagner <torsten.wagner@gmail.com>
To: Org Mode Mailing List <emacs-orgmode@gnu.org>
Subject: Re: [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks
Date: Wed, 24 Jul 2013 10:48:09 +0200 [thread overview]
Message-ID: <CAPaq-gPE_+7X8i+vgTKcemCOfqoxMj00MoaZM3-4UZxb2NN2JA@mail.gmail.com> (raw)
In-Reply-To: <CAPaq-gNxCxkAL2zwZsi=RC7C6=2smNGZXQjdRKoLxDVRNcKKqA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]
Hi Rick, Hi Sebastien,
thanks for your inputs.
Well I guess Sebastien is half-right. The different settings make at least
it even more tricky to see what is going on.
Here is a table with the settings as I found them on my system (which I did
not change)
#+BEGIN_ORG
| org-babel-default-header-args | ((:session . "none") (:results .
"replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines .
"no") (:tangle . "no") (:padnewline . "yes")) |
| org-babel-default-lob-header-args | ((:exports .
"results"))
|
| org-babel-default-inline-header-args | ((:session . "none")(:results .
"replace")(:exports .
"results"))
|
#+END_ORG
As you can see the most prominent cause for trouble might be :hlines
As Rick should in his message it does still not solve all problems but it
helps to make it more clear.
I assume Eric is on holiday or otherwise busy but I guess he will find this
thread and might can give us some idea, whether there was an intention in
dealing with tables in that way or whether it is really considered as a bug.
However, Sebastian pointed out a very important fact. Different default
settings for different ways of calling a source code block. I believe that
this should find its way into the manual.
All the best
Torsten
On 22 July 2013 13:20, Torsten Wagner <torsten.wagner@gmail.com> wrote:
> Hi,
>
> I want to summarize the problem I found, using tables as input to source
> code blocks.
> This observation was shared with Rick and I would be glad to help fixing
> that.
>
> Within the attached file one can see a typical example.
>
> It all comes down to a differently interpretation of tables with respect
> to horizontal line.
>
> #+TBLNAME: with-hline
> | A | B | C |
> |---+---+---|
> | 1 | 2 | 3 |
> | X | Y | Z |
>
> and
>
> #+TBLNAME: without-hline
> | A | B | C |
> | 1 | 2 | 3 |
> | X | Y | Z |
>
> will give different results being called by
>
> #+name: python-element
> #+begin_src python :var table=with-hline :exports results
> return table[1]
> #+end_src
>
> or
>
> #+CALL: python-echo(with-hline)
>
> Please see the attached file for details.
>
> From what I was able to observe:
>
> 1. Calling a table with hline, the result of the source code block miss
> the first row. Indexing is possible only for the second and third row (in
> the given example)
>
> 2. Having no hline, the first row is available, indexing of the first row
> works too.
>
> Using a Call construct:
> 1. for a table without hline, indexing works but it does not work for a
> table with hline.
> 2. Interestingly, using the CALL functions, the type of both tables in
> python is list for the entire table, however, indexing a table with hlines,
> the type becomes NoneType whereas for a table without hline it is still of
> type list.
>
>
> Hope that can somehow help to get an idea what is going on.
>
>
> Greetings
>
> Torsten
>
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 4345 bytes --]
next prev parent reply other threads:[~2013-07-24 8:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-22 11:20 [babel] Table as varaiables a differently proccesed by #+call lines vs. source code blocks Torsten Wagner
2013-07-23 12:25 ` Sebastien Vauban
2013-07-23 15:40 ` Rick Frankel
2013-07-24 8:48 ` Torsten Wagner [this message]
2013-07-24 22:30 ` Eric Schulte
2013-07-25 11:40 ` Torsten Wagner
2013-07-25 12:37 ` Jambunathan K
2013-07-25 13:43 ` Eric Schulte
-- strict thread matches above, loose matches on Subject: below --
2013-07-25 17:02 Rick Frankel
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=CAPaq-gPE_+7X8i+vgTKcemCOfqoxMj00MoaZM3-4UZxb2NN2JA@mail.gmail.com \
--to=torsten.wagner@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).