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

[Eric Schulte <schulte.eric@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/