Re: [O] [Babel][Bug] Inconsistent output from babel function depending on how called

[Ethan Ligon]

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 <address@hidden> wrote:
> Ethan Ligon <address@hidden> 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.

Thanks,
-Ethan

-- 
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley