From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails Date: Tue, 24 Jan 2012 07:52:37 -0700 Message-ID: <87k44hhy7c.fsf@gmx.com> References: <87k44is34h.fsf@gmx.com> <87d3a9n3rs.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:38160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpj3y-0004On-E4 for emacs-orgmode@gnu.org; Tue, 24 Jan 2012 11:17:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rpj3s-00082j-1S for emacs-orgmode@gnu.org; Tue, 24 Jan 2012 11:17:38 -0500 Received: from mailout-us.gmx.com ([74.208.5.67]:47106) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Rpj3r-00082d-PL for emacs-orgmode@gnu.org; Tue, 24 Jan 2012 11:17:32 -0500 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: Leo Alekseyev Cc: Emacs orgmode , Eric Schulte > > Just to be clear, do you consider the following to be an inline block? > (I usually think of inline as limited to src_R{ ...} type things). > Or are you generally talking about the distinction between #+begin_src > / #+end_src lines vs #+call lines? > > #+begin_src R :results output raw replace :exports results > cat.fname.link() > #+end_src > My terminology is inline block :: src_foo{} which can live on a line with text block :: begin/end_src foo, which is a block element call line :: #+call: which lives on a block by itself If /inline blocks/ above don't replace their results above then that is expected. If you can find instances where call lines or blocks don't replace their results then that is a bug. > > Finally, in the last file of my original message I try to use #+call's > everywhere instead of source blocks. Cleaned up example is pasted > below. It looks broken (the first #+call bar is out of order, the > second and third #+call bar's don't run), see > http://pastebin.com/LqYK0Ps2 with my annotation where the output looks > broken > Ah, this is a different issue, but one which should be discussed. I'm happy we're working through all of these before the Emacs24 release. The problem below is not order of evaluation but rather insertion of results. The elements are evaluated in order, but the results from the bar() call lines are all inserted in the same place. In the current code the raw text of the call line is used to insert the results, so identical call lines replace each other's results. So in the following... #+NAME: foo-for-R #+HEADER: :var a="a1.png" #+BEGIN_SRC R :results output silent cat("in foo-for-R block\n") cat.a <- function() { cat(a,"\n",sep="") } cat.a() #+END_SRC #+NAME: bar-for-R #+begin_src R :results output raw replace :exports none cat.a() #+end_src Because there are three instances of the =bar-for-R()= call line, all of their results are inserted into the same place in the file, specifically the location of the =#+Results: bar-for-R()= line. This can be very confusing if you are expected each =bar-for-R()= line to generate it's own results. Should have all a1 stuff #+call: foo-for-R(a="a1.png") #+call: bar-for-R() Should have all a2 stuff #+call: foo-for-R(a="a2.png") #+call: bar-for-R() Should have all a3 stuff #+call: foo-for-R(a="a3.png") #+call: bar-for-R() The solution demonstrated below is to add a nothing header argument to each bar-for-R to make it unique. Notice that the three =foo= lines below don't include results, as their results are inserted at the identical foo lines above. Should have all a1 stuff #+call: foo-for-R(a="a1.png") #+call: bar-for-R[id=1]() Should have all a2 stuff #+call: foo-for-R(a="a2.png") #+call: bar-for-R[id=2]() Should have all a3 stuff #+call: foo-for-R(a="a3.png") #+call: bar-for-R[id=3]() Although the above is a workaround, it may be cumbersome. I'm on the fence about whether to try to change the existing behavior. If each identical call line is thought of as a token of the same call then maybe it makes sense to have only one location in which to insert the results of that call (also it is possible that some users are relying on the current behavior). That said it is certainly confusing... -- Eric Schulte http://cs.unm.edu/~eschulte/