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: Mon, 23 Jan 2012 21:50:53 -0600 Message-ID: References: <87k44is34h.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]:46181) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpXPN-0005Wt-BJ for emacs-orgmode@gnu.org; Mon, 23 Jan 2012 22:50:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpXPL-0006DG-G2 for emacs-orgmode@gnu.org; Mon, 23 Jan 2012 22:50:57 -0500 Received: from mail-pw0-f41.google.com ([209.85.160.41]:36799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpXPL-00067B-11 for emacs-orgmode@gnu.org; Mon, 23 Jan 2012 22:50:55 -0500 Received: by mail-pw0-f41.google.com with SMTP id u6so2382354pbd.0 for ; Mon, 23 Jan 2012 19:50:53 -0800 (PST) In-Reply-To: <87k44is34h.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 On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte wrote= : > Leo Alekseyev writes: > >> Since all source blocks are evaluated on export, I don't think it >> should be necessary to issue org-babel-execute-buffer before invoking >> export. =A0However, running HTML export without org-babel-execute-buffer >> currently produces garbage output. >> > > What do you mean by "garbage" output? That wasn't a very good description, sorry. ...... I just wrote a detailed description of the bug, and then remembered that I forgot to copy the latest org pull into /usr/share/emacs/24/lisp/org. This bug is now gone, probably as a result of you fixing export evaluation order. However, the description of "replace results" bug is still relevant. I'll denote issues that are now fixed with appropriate markup. #+BEGIN_MOOT_POINT Take test-export4.org from my original message, and export (C-c C-e h; don't evaluate the buffer beforehand). You will see the following output: http://i.imgur.com/IM3oy.png There are two problems: (1) Notice that the output of _every_ src_R block is "images/conv2.png" It should be "conv1.png" on the first invocation "conv2.png" on the second, and "conv3.png" on the third. (2) The last src_R block is not evaluated and, in fact, appears in the output (which it shouldn't), mangled, as the underscore is taken as a subscript. #+END_MOOT_POINT For comparison, if you first evaluate the buffer, and then export, you will see this: http://i.imgur.com/V6PXq.png The output of the src_R blocks is now correct, but I don't see why one needs to pre-evaluate the buffer to get correct output on export. The overall output, as you can see, is _not_ correct, since the results from invocation of src_R blocks via the export are _appended_ to those that were generated via C-c C-v b. > > Could you isolate a minimal example demonstrating just the failure of > results replacement? Run the below code a few times with C-c C-v b, and you'll see ------------snip--------- #+property: session *R-babel* #+NAME: foo #+HEADER: :var plot.filename=3D"conv1.png" #+BEGIN_SRC R :results output silent cat.fname.link <- function() { cat(plot.filename,"\n",sep=3D"") } cat.fname.link() #+END_SRC src_R[:results output replace]{ cat.fname.link() } ------------snip--------- You can also replace src_R with #+begin_src R :results output raw replace :exports results cat.fname.link() #+end_src and it will also fail to replace results. All the above examples were run with the latest pull of org. HTH, --Leo