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: Fri, 27 Jan 2012 15:43:33 -0700 Message-ID: <87r4ykaez1.fsf@gmx.com> References: <87k44is34h.fsf@gmx.com> <87d3a9n3rs.fsf@gmx.com> <87k44hhy7c.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:49046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqvSg-0007NK-Rb for emacs-orgmode@gnu.org; Fri, 27 Jan 2012 18:44:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqvSe-00019r-1X for emacs-orgmode@gnu.org; Fri, 27 Jan 2012 18:44:06 -0500 Received: from mailout-us.gmx.com ([74.208.5.67]:55531 helo=mailout-us.mail.com) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RqvSd-00019f-PF for emacs-orgmode@gnu.org; Fri, 27 Jan 2012 18:44:04 -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 Leo Alekseyev writes: >> >> If /inline blocks/ above don't replace their results above then that is >> expected. =C2=A0If you can find instances where call lines or blocks don= 't >> replace their results then that is a bug. > > Yes, I was finding that neither inline nor regular blocks replace: run > the following with C-c C-v b a few times and look at the block output > > -----snip------ > #+property: session *R-babel* > > #+NAME: foo > #+HEADER: :var a=3D"a1.png" > #+BEGIN_SRC R :results output silent > cat("in foo block\n") > cat.a <- function() { cat(a,"\n",sep=3D"") } > cat.a() > #+END_SRC > #+call: foo(a=3D"a1.png") > > #+begin_src R :results output raw replace :exports results > cat.a() > #+end_src > ----------snip--------- > OK, I see what you mean. When I evaluate this buffer multiple times the results of the #+call: line *are* replaced as expected, but the final code block can not replace it's results because of the "raw" option to the :results header argument. The "raw" and "replace" header arguments are not compatible because with raw results there is no way to know where the results end. I believe this is mentioned in the manual, if not it should be. > > >> >>> >>> Finally, in the last file of my original message I try to use #+call's >>> everywhere instead of source blocks. =C2=A0Cleaned up example is pasted >>> below. =C2=A0It 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. =C2=A0= 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. =C2=A0The elements are evaluated in order, but the results from= the >> bar() call lines are all inserted in the same place. =C2=A0In 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. > > ....... > >>> Although the above is a workaround, it may be cumbersome. =C2=A0I'm on = the >> fence about whether to try to change the existing behavior. =C2=A0If 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). =C2=A0That said it is certainly confusing... > > I see no reason why we should think of each call line as a token of > the same call; do you? In fact, it's probably a fundamentally flawed > way of thinking, because nothing guarantees that the global state of > the session hasn't changed between call invocations. In fact, in that > sense, we can't even technically regard the _same_ call line as being > a token of the same call, if we consider it at different times :) > I'm inclined to agree with you. > > Referring to what I said in another thread ("the principle of least > surprise"): it makes a lot of sense for the call lines to behave the > same way a function call, or a source() statement would behave in the > interpreter session of the original language. From that perspective, > the current behavior seems wrong. Can you come up with a scenario / > usage pattern where the current behavior is more desirable? > The only loss of functionality would be the ability in the existing model to have a call line and it's results live in separate locations. Given that call lines can not currently be named their results are named by the information on the call line (called function, header arguments, etc...) which will be identical for identical call lines, leading to the current confusing behavior. I think the best way forward would be to 1. stop auto-naming #+call: lines as we are currently and instead leave their results anonymous as with code blocks, and by default inserted immediately after the #+call: line. 2. allow names to be applied to call lines, which can then be used to identify their results and locate their results remotely in the buffer. If this sounds like a good way forward then I'll put it on my queue for some time in the when-I-have-more-time future. :) Best, > > --Leo > --=20 Eric Schulte http://cs.unm.edu/~eschulte/