From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Anders Subject: Re: [org-babel] switching off (re-)evaluation of code blocks during Org export Date: Mon, 28 Nov 2011 10:01:04 +0000 Message-ID: <88823ACF-7E81-4342-AF2F-685A0E8F5B26@beds.ac.uk> References: <2A2CA71C-50E6-4533-BD40-2D879EF3BBCC@beds.ac.uk> <87aa7plzl8.fsf@gmail.com> <87y5v067oe.fsf@gmail.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([140.186.70.92]:43800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUy46-0006XG-3w for emacs-orgmode@gnu.org; Mon, 28 Nov 2011 05:04:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RUy44-0006gh-6w for emacs-orgmode@gnu.org; Mon, 28 Nov 2011 05:03:57 -0500 Received: from smtp.idnet.com ([212.69.40.133]:41614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RUy43-0006gM-SM for emacs-orgmode@gnu.org; Mon, 28 Nov 2011 05:03:56 -0500 In-Reply-To: <87y5v067oe.fsf@gmail.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: Org-mode Dear Eric, Sorry for the noise, it works fine.=20 > see the manual for valid values for the eval header argument. I actually did, but only the online version so far. Of course, for such = changes I had to check the doc sources... Anyway, thanks a lot!!=20 Best wishes, Torsten On 28 Nov 2011, at 07:13, Eric Schulte wrote: > Hi Torsten, >=20 > Change "non-export" to "no-export", see the manual for valid values = for > the eval header argument. >=20 > Best -- Eric >=20 > Torsten Anders writes: >=20 >> Dear Eric, >>=20 >> Apologies for my late response (too much teaching and admin in this = new job :-P). Thanks a lot again for kingly adding the "eval" header >> argument "non-export". =46rom what I understand in your message this = would be exactly what I was looking for (allow interactive >> evaluation, but inhibit code block evaluation during export). I just = pulled the latest org sources and tested your addition.=20 >>=20 >> Unfortunately, even when using this header argument value, code = blocks in both Lilypond and Fomus are still executed when the buffer is = exported to either PDF (via Latex) or HTML.=20 >>=20 >> Below is a test that I understood should not execute during export. = Am I missing something? >>=20 >>=20 >> #+begin_src fomus :eval non-export :results silent :file = fomus-test.ly >> time 1 dur 1 pitch 60; >> #+end_src >> [[file:fomus-test.pdf]] >>=20 >> Thanks a lot again!=20 >>=20 >> Best wishes, >> Torsten >>=20 >>=20 >> On 22 Nov 2011, at 01:23, Eric Schulte wrote: >>=20 >>> Hi Torsten, >>>=20 >>> Torsten Anders writes: >>>=20 >>>> Dear Sebastien and Eric, >>>>=20 >>>> Thanks a lot for your kind replies. However, this is not yet quite = what I am after. >>>>=20 >>>> I want to be able to manually execute each code block, but not >>>> automatically whenever the whole document is rendered. So, I would >>>> always switch on/off "eval never". Hm... >>>>=20 >>>=20 >>> I've just pushed up a patch which adds a new option to the "eval" = header >>> argument. Setting eval to "non-export" will now allow interactive >>> evaluation, but will inhibit code block evaluation during export. = This >>> should address your need as I understand it. >>>=20 >>>>=20 >>>> I will try out the ":cache" header argument. However, again this = does >>>> not work so well, because for the languages I am using the :file >>>> argument does not work very well (I have to manually change >>>> extensions, so I include the resulting file links by hand anyway = and >>>> set :results to silent. >>>>=20 >>>> So, I it sounds like few org-babel users is really running larger >>>> applications in their code blocks which can delay the export of the >>>> whole document considerably. >>>>=20 >>>=20 >>> I would not jump to that conclusion. I have used babel code blocks = to >>> cache the results of very long running results, however between the >>> :cache header argument and the ability to manually disassociate >>> generated results from code blocks I have not had any problems >>> inhibiting execution during export. >>>=20 >>> Best -- Eric >>>=20 >>>>=20 >>>> Anyway, thanks a lot for your feedback. >>>>=20 >>>> Best wishes, >>>> Torsten >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> --=20 >>> Eric Schulte >>> http://cs.unm.edu/~eschulte/ >>=20 >=20 > --=20 > Eric Schulte > http://cs.unm.edu/~eschulte/