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.e...@gmail.com> wrote: > Torsten Wagner <torsten.wag...@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.wag...@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 >
babel_standard_header_settings_doc.patch
Description: Binary data
