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/
