* [Babel][Bug] Inconsistent output from babel function depending on how called
@ 2011-05-26 18:37 Ethan Ligon
2011-05-26 18:46 ` Eric Schulte
0 siblings, 1 reply; 8+ messages in thread
From: Ethan Ligon @ 2011-05-26 18:37 UTC (permalink / raw)
To: Emacs-orgmode@gnu.org
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?
Thoughts, patches, or work-arounds welcomed!
Thanks,
-Ethan
--
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Babel][Bug] Inconsistent output from babel function depending on how called
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-26 19:36 ` Ethan Ligon
0 siblings, 2 replies; 8+ messages in thread
From: Eric Schulte @ 2011-05-26 18:46 UTC (permalink / raw)
To: Ethan Ligon; +Cc: Emacs-orgmode@gnu.org
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
Best -- Eric
>
> Thoughts, patches, or work-arounds welcomed!
>
> Thanks,
> -Ethan
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Babel][Bug] Inconsistent output from babel function depending on how called
2011-05-26 18:46 ` Eric Schulte
@ 2011-05-26 19:17 ` Christian Moe
2011-05-27 1:04 ` Ethan Ligon
2011-05-27 16:35 ` Eric Schulte
2011-05-26 19:36 ` Ethan Ligon
1 sibling, 2 replies; 8+ messages in thread
From: Christian Moe @ 2011-05-26 19:17 UTC (permalink / raw)
To: Eric Schulte; +Cc: Ethan Ligon, Emacs-orgmode@gnu.org
> 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.
Yours,
Christian
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Babel][Bug] Inconsistent output from babel function depending on how called
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
1 sibling, 1 reply; 8+ messages in thread
From: Ethan Ligon @ 2011-05-27 1:04 UTC (permalink / raw)
To: mail; +Cc: Emacs-orgmode@gnu.org
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
--
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [Babel][Bug] Inconsistent output from babel function depending on how called
2011-05-27 1:04 ` Ethan Ligon
@ 2011-05-27 15:28 ` Eric Schulte
0 siblings, 0 replies; 8+ messages in thread
From: Eric Schulte @ 2011-05-27 15:28 UTC (permalink / raw)
To: Ethan Ligon; +Cc: Emacs-orgmode@gnu.org, mail
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Babel][Bug] Inconsistent output from babel function depending on how called
2011-05-26 19:17 ` Christian Moe
2011-05-27 1:04 ` Ethan Ligon
@ 2011-05-27 16:35 ` Eric Schulte
1 sibling, 0 replies; 8+ messages in thread
From: Eric Schulte @ 2011-05-27 16:35 UTC (permalink / raw)
To: mail; +Cc: Ethan Ligon, Emacs-orgmode@gnu.org
Christian Moe <mail@christianmoe.com> writes:
>> 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.
>
> Yours,
> Christian
I've just updated the documentation at the following to reflect the full
range of #+call line header argument options.
#+begin_src emacs-lisp
(info "(org)Evaluating code blocks")
#+end_src
Thanks for the recommendation -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Babel][Bug] Inconsistent output from babel function depending on how called
2011-05-26 18:46 ` Eric Schulte
2011-05-26 19:17 ` Christian Moe
@ 2011-05-26 19:36 ` Ethan Ligon
2011-05-26 23:57 ` Eric Schulte
1 sibling, 1 reply; 8+ messages in thread
From: Ethan Ligon @ 2011-05-26 19:36 UTC (permalink / raw)
To: Eric Schulte; +Cc: Emacs-orgmode@gnu.org
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.
Thanks,
-Ethan
--
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Babel][Bug] Inconsistent output from babel function depending on how called
2011-05-26 19:36 ` Ethan Ligon
@ 2011-05-26 23:57 ` Eric Schulte
0 siblings, 0 replies; 8+ messages in thread
From: Eric Schulte @ 2011-05-26 23:57 UTC (permalink / raw)
To: Ethan Ligon; +Cc: Emacs-orgmode@gnu.org
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/
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-05-27 16:35 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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).