Dear Eric, Sorry for the noise, it works fine.
> 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!! Best wishes, Torsten On 28 Nov 2011, at 07:13, Eric Schulte wrote: > Hi Torsten, > > Change "non-export" to "no-export", see the manual for valid values for > the eval header argument. > > Best -- Eric > > Torsten Anders <torsten.and...@beds.ac.uk> writes: > >> Dear Eric, >> >> 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". From 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. >> >> 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. >> >> Below is a test that I understood should not execute during export. Am I >> missing something? >> >> >> #+begin_src fomus :eval non-export :results silent :file fomus-test.ly >> time 1 dur 1 pitch 60; >> #+end_src >> [[file:fomus-test.pdf]] >> >> Thanks a lot again! >> >> Best wishes, >> Torsten >> >> >> On 22 Nov 2011, at 01:23, Eric Schulte wrote: >> >>> Hi Torsten, >>> >>> Torsten Anders <torsten.and...@beds.ac.uk> writes: >>> >>>> Dear Sebastien and Eric, >>>> >>>> Thanks a lot for your kind replies. However, this is not yet quite what I >>>> am after. >>>> >>>> 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... >>>> >>> >>> 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. >>> >>>> >>>> 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. >>>> >>>> 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. >>>> >>> >>> 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. >>> >>> Best -- Eric >>> >>>> >>>> Anyway, thanks a lot for your feedback. >>>> >>>> Best wishes, >>>> Torsten >>>> >>>> >>>> >>>> >>> >>> -- >>> Eric Schulte >>> http://cs.unm.edu/~eschulte/ >> > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/
