From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ethan Ligon Subject: Re: [Babel][Bug] Inconsistent output from babel function depending on how called Date: Thu, 26 May 2011 18:04:22 -0700 Message-ID: References: <87wrhdqozg.fsf@gmail.com> <4DDEA75B.4040601@christianmoe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:53732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPlTo-00077R-9M for emacs-orgmode@gnu.org; Thu, 26 May 2011 21:04:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QPlTn-00073Z-4g for emacs-orgmode@gnu.org; Thu, 26 May 2011 21:04:44 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:64051) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPlTm-00073T-VX for emacs-orgmode@gnu.org; Thu, 26 May 2011 21:04:43 -0400 Received: by fxm18 with SMTP id 18so1245504fxm.0 for ; Thu, 26 May 2011 18:04:42 -0700 (PDT) In-Reply-To: <4DDEA75B.4040601@christianmoe.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: mail@christianmoe.com Cc: "Emacs-orgmode@gnu.org" On Thu, May 26, 2011 at 12:17 PM, Christian Moe wro= te: >> No, this is expected (if possibly under-documented behavior). =A0The >> :results header arguments are associated with the code block and *not* >> with the #+call line. =A0To get the desired behavior, you must specify t= he >> :results header argument on the #+call: line thusly. >> >> #+call: print_list(lst=3Dlist1) :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 co= de > 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=3Dlist1) :results org #+results: print_list[:results output](lst=3Dlist1) #+BEGIN_ORG * Item1 * Item2 #+END_ORG but this way of calling doesn't #+call: print_list[:results output org](lst=3Dlist2) #+results: print_list[:results output org](lst=3Dlist2) : * Item3 : * Item4 and neither does this way #+call: print_list[:results org](lst=3Dlist2) :results output #+results: print_list[:results org](lst=3Dlist2) or this way #+call: print_list(lst=3Dlist2) :results output org #+results: print_list(lst=3Dlist2) #+END_ORG #+BEGIN_ORG Thanks for any enlightenment! -Ethan --=20 Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley