From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Alekseyev Subject: Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails Date: Tue, 24 Jan 2012 17:35:31 -0600 Message-ID: References: <87k44is34h.fsf@gmx.com> <87d3a9n3rs.fsf@gmx.com> <87k44hhy7c.fsf@gmx.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]:36313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpptn-0006si-D7 for emacs-orgmode@gnu.org; Tue, 24 Jan 2012 18:35:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rpptl-0007Cx-6E for emacs-orgmode@gnu.org; Tue, 24 Jan 2012 18:35:35 -0500 Received: from mail-pw0-f41.google.com ([209.85.160.41]:34388) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpptk-0007Cq-VE for emacs-orgmode@gnu.org; Tue, 24 Jan 2012 18:35:33 -0500 Received: by pbaa12 with SMTP id a12so409742pba.0 for ; Tue, 24 Jan 2012 15:35:32 -0800 (PST) In-Reply-To: <87k44hhy7c.fsf@gmx.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: Eric Schulte Cc: Emacs orgmode > > If /inline blocks/ above don't replace their results above then that is > expected. =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--------- > >> >> Finally, in the last file of my original message I try to use #+call's >> everywhere instead of source blocks. =A0Cleaned up example is pasted >> below. =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. =A0I'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. =A0The elements are evaluated in order, but the results from the > bar() call lines are all inserted in the same place. =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. =A0I'm on the > fence about whether to try to change the existing behavior. =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). =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 :) 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? --Leo