emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

  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).