From: Eric Schulte <schulte.eric@gmail.com>
To: Ethan Ligon <ligon@are.berkeley.edu>
Cc: "Emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>, mail@christianmoe.com
Subject: Re: [Babel][Bug] Inconsistent output from babel function depending on how called
Date: Fri, 27 May 2011 09:28:07 -0600 [thread overview]
Message-ID: <87hb8g6u48.fsf@gmail.com> (raw)
In-Reply-To: <BANLkTinHgX__bKUqwSEBsuwsnAnLZvp1MQ@mail.gmail.com> (Ethan Ligon's message of "Thu, 26 May 2011 18:04:22 -0700")
Ethan Ligon <ligon@are.berkeley.edu> writes:
> On Thu, May 26, 2011 at 12:17 PM, Christian Moe <mail@christianmoe.com> wrote:
>>> No, this is expected (if possibly under-documented behavior). The
>>> :results header arguments are associated with the code block and *not*
>>> with the #+call line. To get the desired behavior, you must specify the
>>> :results header argument on the #+call: line thusly.
>>>
>>> #+call: print_list(lst=list1) :results output org
>>>
>>> Best -- Eric
>>
>> Hi,
>>
>> I recently made the same mistake, and it took me a while to figure things
>> out. I had assumed #+CALLs inherited all the header arguments from the code
>> blocks they referenced.
>>
>> Regarding documentation, I see now that the correct behavior is at least
>> implicitly documented in the first example at
>> [[info:org#Header%20arguments%20in%20function%20calls]].
>>
>> It might rate an explicit explanation at
>> [[info:org#Evaluating%20code%20blocks]] as well, though.
>>
>
> I'd be happy to help with the documentation, but I still don't
> understand the behavior. It seems as though some arguments
> to :results need to be supplied to the code block, but others have to
> be supplied to the call. In my situation, the "org" option
> to :results has to be supplied to the call, while the "output" option
> has to be supplied to the code block.
>
> What's the logic?
>
> Here's my setup:
>
> #+results: list1
> - Item1
> - Item2
>
>
> #+results: list2
> - Item3
> - Item4
>
> #+source: print_list(lst)
> #+begin_src sh
> for i in $lst; do
> echo "* $i"
> done
> #+end_src
>
> Here's a way of calling that works
> #+call: print_list[:results output](lst=list1) :results org
>
> #+results: print_list[:results output](lst=list1)
> #+BEGIN_ORG
> * Item1
> * Item2
> #+END_ORG
>
> but this way of calling doesn't
> #+call: print_list[:results output org](lst=list2)
>
> #+results: print_list[:results output org](lst=list2)
> : * Item3
> : * Item4
>
> and neither does this way
> #+call: print_list[:results org](lst=list2) :results output
>
> #+results: print_list[:results org](lst=list2)
>
> or this way
> #+call: print_list(lst=list2) :results output org
>
> #+results: print_list(lst=list2)
> #+END_ORG
> #+BEGIN_ORG
>
> Thanks for any enlightenment!
> -Ethan
Hi Ethan,
There are two different places for specifying header argument in a
#+call line, these places are marked with XXXX and YYYY in the
following, both are optional...
#+call: code_bloc_name[XXXX](arguments) YYYY
Header arguments located in these two locations are treated differently.
- XXXX :: Those placed in the XXXX location are passed through and
applied to the code block being called. These header arguments
affect how the code block is evaluated, for example [:results
output] will collect the results from STDOUT of the called code
block.
- YYYY :: Those placed in the YYYY location are applied to the call line
and do not affect the code block being called. These header
arguments affect how the results are incorporated into the Org-mode
buffer when the #+call line is evaluated, and how the #+call line
is exported. For example ":results org" at the end of the call
line will insert the results of the call line in an Org-mode block.
Is this more clear? Is there a way it can be made more straightforward?
If the above seems reasonable then I can add it to the documentation.
Thanks -- Eric
next prev parent reply other threads:[~2011-05-27 15:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-26 18:37 [Babel][Bug] Inconsistent output from babel function depending on how called Ethan Ligon
2011-05-26 18:46 ` Eric Schulte
2011-05-26 19:17 ` Christian Moe
2011-05-27 1:04 ` Ethan Ligon
2011-05-27 15:28 ` Eric Schulte [this message]
2011-05-27 16:35 ` Eric Schulte
2011-05-26 19:36 ` Ethan Ligon
2011-05-26 23:57 ` Eric Schulte
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=87hb8g6u48.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=ligon@are.berkeley.edu \
--cc=mail@christianmoe.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).