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: Sat, 28 Jan 2012 17:07:39 -0600 Message-ID: References: <87k44is34h.fsf@gmx.com> <87d3a9n3rs.fsf@gmx.com> <87k44hhy7c.fsf@gmx.com> <87r4ykaez1.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]:36952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrHN1-0002ct-4N for emacs-orgmode@gnu.org; Sat, 28 Jan 2012 18:07:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrHMz-0006p5-5R for emacs-orgmode@gnu.org; Sat, 28 Jan 2012 18:07:43 -0500 Received: from mail-pz0-f41.google.com ([209.85.210.41]:58009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrHMy-0006p0-V6 for emacs-orgmode@gnu.org; Sat, 28 Jan 2012 18:07:41 -0500 Received: by dake40 with SMTP id e40so2675074dak.0 for ; Sat, 28 Jan 2012 15:07:39 -0800 (PST) In-Reply-To: <87r4ykaez1.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 >> >> -----snip------ >> #+property: session *R-babel* >> >> #+NAME: foo >> #+HEADER: :var a=3D"a1.png" >> #+BEGIN_SRC R :results output silent >> =A0 cat("in foo block\n") >> =A0 cat.a <- function() { cat(a,"\n",sep=3D"") } >> =A0 cat.a() >> #+END_SRC >> #+call: foo(a=3D"a1.png") >> >> #+begin_src R :results output raw replace :exports results >> =A0cat.a() >> #+end_src >> ----------snip--------- >> > > OK, I see what you mean. =A0When I evaluate this buffer multiple times th= e > 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. =A0The "raw" and "replace" header arguments > are not compatible because with raw results there is no way to know > where the results end. =A0I believe this is mentioned in the manual, if > not it should be. Ok, I see. Ideally, incompatible arguments should trigger an error condition that would be communicated to the user (at the very least, by printing a message in the minibuffer). Silent failures are annoying, even if documented :) On a more practical note, is there _a_ method of achieving what I'm trying to do here, namely, to place an image in the buffer in a way that would be understood by Org and that would be properly imported in HTML? >> Referring to what I said in another thread ("the principle of least >> surprise"): =A0it 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. =A0From that perspective, >> the current behavior seems wrong. =A0Can 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 > =A0 their results anonymous as with code blocks, and by default inserted > =A0 immediately after the #+call: line. > > 2. allow names to be applied to call lines, which can then be used to > =A0 identify their results and locate their results remotely in the > =A0 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. :) Yes, I think it's a good long-term plan. Enqueue it :) In the meantime, the current behavior (and the possible workaround) should probably be mentioned in the docs if it isn't already. --Leo