From: Eric Schulte <schulte.eric@gmail.com>
To: Ethan Ligon <ligon@are.berkeley.edu>
Cc: "Emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: [Babel][Bug] Inconsistent output from babel function depending on how called
Date: Thu, 26 May 2011 17:57:35 -0600 [thread overview]
Message-ID: <87boyo6u0i.fsf@gmail.com> (raw)
In-Reply-To: BANLkTinp91oW-JE0-Zb7pvojCP3OHozcuA@mail.gmail.com
Ethan Ligon <ligon@are.berkeley.edu> writes:
> So, the ":result output org" ought to be associated with the *call*,
> not with the function. That makes good sense. But perhaps it still
> doesn't work quite as it ought...
>
> On Thu, May 26, 2011 at 11:46 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> Ethan Ligon <ligon@are.berkeley.edu> writes:
>>
>>> I'd like to call a simple babel code block to generate org-code
>>> If I define a list thusly:
>>>
>>> #+results: list1
>>> - foo
>>> - bar
>>>
>>> Then I define a code block thusly, and execute it by C-c C-c on the
>>> "source" line. That yields the desired result: a sequence of headings
>>> under "#+results: print_list".
>>>
>>> #+source: print_list(lst=list1)
>>> #+begin_src sh :results output org
>>> for i in $lst; do
>>> echo "* $i"
>>> done
>>> #+end_src
>>>
>>> #+results: print_list
>>> #+BEGIN_ORG
>>> * foo
>>> * bar
>>> #+END_ORG
>>>
>>> Now I want to reuse the code block to generate other sequences of
>>> headings. But even if I call it with the *same* list, instead of the
>>> desired headings, I get a literal, as below.
>>>
>>> #+call: print_list(lst=list1)
>>>
>>> #+results: print_list(lst=list1)
>>> : * foo
>>> : * bar
>>>
>>> I think this qualifies as a bug---surely the method of calling the
>>> code block shouldn't affect the output?
>>>
>>
>> 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
>>
>
> If I do this, I get
> #+results: print_list(lst=list1)
> #+END_ORG
> #+BEGIN_ORG
>
> which is surprising first because there's no proper output, but also
> because the end and begin tags are reversed (!).
>
> What *does* work is to omit the "output" header argument.
> #+call: print_list(lst=list1) :results org
>
> #+results: print_list(lst=list1)
> #+BEGIN_ORG
> * foo
> * bar
> #+END_ORG
>
> So now I definitely have a good work-around, but still think there's a
> bug.
>
Well yes and no...
There is a bug here, but not in the interpretation of the header
arguments... the interpretation is just so non-intuitive that I also
misunderstood the resulting behavior in my earlier reply.
In the example of
#+call: print_list(lst=list1) :results output org
both the "org" and "output" header arguments are applied to the call
line, when in fact the output header argument should be applied to the
list1 code block (not the call line). The results of applying the
"output" header argument to the call line is to return no results (which
makes sense because the call line does not print to STDOUT). The
correct form of the above would be as follows (explicitly passing the
"output" header argument to the list1 code block)
#+call: list1[:results output](lst="~/Desktop") :results org
#+results: list1[:results output](lst="~/Desktop")
#+BEGIN_ORG
* ~/Desktop
#+END_ORG
There is an error however in that when no results are returned the
begin/end parts of the Org-mode code block are flipped...
>
> Thanks,
> -Ethan
--
Eric Schulte
http://cs.unm.edu/~eschulte/
prev parent reply other threads:[~2011-05-27 15:30 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
2011-05-27 16:35 ` Eric Schulte
2011-05-26 19:36 ` Ethan Ligon
2011-05-26 23:57 ` Eric Schulte [this message]
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=87boyo6u0i.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=ligon@are.berkeley.edu \
/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).