From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Landis Subject: Re: Selectively export RESULTS Date: Fri, 2 Mar 2012 18:33:56 +0000 (UTC) Message-ID: References: <87ty2aw7ps.fsf@tajo.ucsd.edu> <87ty29eg8n.fsf@tajo.ucsd.edu> <87boohbmch.fsf@gmx.com> <8762epz8uh.fsf@tajo.ucsd.edu> <87mx7ynbbm.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:47724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3XJ0-00056v-T4 for emacs-orgmode@gnu.org; Fri, 02 Mar 2012 13:34:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S3XIy-0007Vw-QU for emacs-orgmode@gnu.org; Fri, 02 Mar 2012 13:34:14 -0500 Received: from plane.gmane.org ([80.91.229.3]:55699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S3XIy-0007Um-Jh for emacs-orgmode@gnu.org; Fri, 02 Mar 2012 13:34:12 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S3XIu-0003Rm-Kg for emacs-orgmode@gnu.org; Fri, 02 Mar 2012 19:34:08 +0100 Received: from 75-150-119-9-NewEngland.hfc.comcastbusiness.net ([75.150.119.9]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Mar 2012 19:34:08 +0100 Received: from landis by 75-150-119-9-NewEngland.hfc.comcastbusiness.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Mar 2012 19:34:08 +0100 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: emacs-orgmode@gnu.org Eric Schulte gmx.com> writes: > > Matthew Landis isciences.com> writes: > > Have you tried this? The cache header argument has special handling of > code blocks with sessions to handle such cases. Fair enough! I hadn't tried it. But I did just try this example: ------------------------------------- #+TITLE: Super simple example using cache header arguments #+PROPERTIES: eval no Here is a really simple example. #+begin_src R :session :results silent :exports code :cache yes x <- rnorm(100) cat('ran this code block') #+end_src here is code block two. #+begin_src R :session :results graphics :exports both :file hist.png :cache yes hist(x, main = 'A new title' ) #+end_src #+results[1987d49b46ffd8b7263dc04e7c7b5d25f90342aa]: [[file:hist.png]] --------------------------------- RESULTS: On 1st export to html, both code blocks are run, and #+results block is *not* created. On 2nd export, both code blocks are run again, counter to my desires. IF I run the code blocks interactively first using C-c C-c, the #+results block is created for the code block 2. After that, subsequent exports run code block 1 but not code block 2. Again, this is counter to my desires because I want code block 1 to be ignored as well. I understand why code block 1 is rerun, because I have :results silent, but I'd rather not have to change that. Generally, code block 1 is producing large R data.frames which don't need to be viewed anywhere. > Are you requesting a new option to :cache, such that even if the code > block has changes the old results are used anyway? Sort of. I think I'm asking for a file wide option to decide whether to run any code blocks, or just do the export based on whatever is currently existing in the #+results blocks. As in this example, I tried #+PROPERTIES: eval no but it is ignored. It would be great if I could set an eval argument at the top of the file to be either 'no' (don't run any code blocks) 'yes' (run all code blocks) or 'block' respect block level eval settings Maybe such functionality exists in some other way - I claim only beginners knowledge of org-babel.