Dear Eric,

please find attached a patch, to describe the different standard values for
system-wide header arguments in the manual.
Hope that might help to avoid confusion in the future.

All the best

Torsten


On 25 July 2013 00:30, Eric Schulte <schulte.eric@gmail.com> wrote:

> Torsten Wagner <torsten.wagner@gmail.com> writes:
>
> > 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.
> >
>
> This is related to
> http://thread.gmane.org/gmane.emacs.orgmode/73976/focus=74175.
>
> >
> > 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.
> >
>
> Yes, I've been very busy.
>
> >
> > 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.
> >
>
> I'm happy to apply patches to 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
> >>
> >>
> >>
> >>
> >>
> >>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte
>