From: Torsten Wagner <torsten.wagner@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: 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: Thu, 25 Jul 2013 13:40:23 +0200 [thread overview]
Message-ID: <CAPaq-gM=usFEkj8HkSXtSVMw1VSXzK7RT1nd7o-1GaYHyhS7Ug@mail.gmail.com> (raw)
In-Reply-To: <87y58voaa7.fsf@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3844 bytes --]
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
>
[-- Attachment #1.2: Type: text/html, Size: 5700 bytes --]
[-- Attachment #2: babel_standard_header_settings_doc.patch --]
[-- Type: application/octet-stream, Size: 1360 bytes --]
diff --git a/doc/org.texi b/doc/org.texi
index 55c421d..d8987d6 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14066,6 +14066,16 @@ blocks.
(assq-delete-all :noweb org-babel-default-header-args)))
@end lisp
+The different ways of calling a source code block might come with different system-wide values of header arguments.
+Thus, the behaviour of a source code block might differ, depending on the way how it was called. The table below depicts the variables and standard values for the different ways to execute a source code block.
+
+@multitable @columnfractions 0.1 0.1 0.3
+@item @b{Method} @tab @b{Variable} @tab @b{Values}
+@item source code block @tab org-babel-default-header-args @tab :session "none", :results "replace", :exports "code", :cache "no", :noweb "no", :hlines "no", :tangle "no", :padnewline "yes"
+@item inline call @tab org-babel-default-inline-header-args @tab :exports "results"
+@item function calls @tab org-babel-default-lob-header-args @tab :session "none", :results "replace", :exports "results"
+@end multitable
+
@node Language-specific header arguments, Header arguments in Org mode properties, System-wide header arguments, Using header arguments
@subsubheading Language-specific header arguments
Each language can define its own set of default header arguments in variable
next prev parent reply other threads:[~2013-07-25 11:40 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
2013-07-24 22:30 ` Eric Schulte
2013-07-25 11:40 ` Torsten Wagner [this message]
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-gM=usFEkj8HkSXtSVMw1VSXzK7RT1nd7o-1GaYHyhS7Ug@mail.gmail.com' \
--to=torsten.wagner@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/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).