Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
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 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 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/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Torsten, Change "non-export" to "no-export", see the manual for valid values for the eval header argument. Best -- Eric Torsten Anders 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 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/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
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 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/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Bernt Hansen writes: > Eric Schulte writes: > >>> >>> Hence, maybe we should be able to set 2 possible behaviors[1] for the >>>`eval' >>> parameter: >>> >>> - one for the interactive mode (yes/query/no), and >>> - one for the export mode (yes/no, and maybe query as well?). >>> >> >> Agreed, >> >> The eval header argument now supports the following four options >> (updated in the manual under "Specific header arguments"). >> >> | no or never | no evaluation anytime | >> | query | query before evaluation anytime | >> | no-eval or never-eval | no evaluation during export | >> | query-eval| query before evaluation during export | >> >> Thanks for the suggestion > > Hi Eric, > > Should the last two be named export-no, export-never, and export-query. > That seems more self-documenting to me. > Oh!, I miss-typed the above it should read as follows. | no or never | no evaluation anytime | | query | query before evaluation anytime | | no-export or never-export | no evaluation during export | | query-export | query before evaluation during export | Thanks for catching this, the documentation has the correct terms. Best, > > I'm going to be confused about the difference between 'no' and 'no-eval' > in the future. Since the eval header argument already has 'eval' in it > is it not more useful to specify these values are export related? > > Regards, > Bernt -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Eric Schulte writes: >> >> Hence, maybe we should be able to set 2 possible behaviors[1] for the >>`eval' >> parameter: >> >> - one for the interactive mode (yes/query/no), and >> - one for the export mode (yes/no, and maybe query as well?). >> > > Agreed, > > The eval header argument now supports the following four options > (updated in the manual under "Specific header arguments"). > > | no or never | no evaluation anytime | > | query | query before evaluation anytime | > | no-eval or never-eval | no evaluation during export | > | query-eval| query before evaluation during export | > > Thanks for the suggestion Hi Eric, Should the last two be named export-no, export-never, and export-query. That seems more self-documenting to me. I'm going to be confused about the difference between 'no' and 'no-eval' in the future. Since the eval header argument already has 'eval' in it is it not more useful to specify these values are export related? Regards, Bernt
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
> > Hence, maybe we should be able to set 2 possible behaviors[1] for the >`eval' > parameter: > > - one for the interactive mode (yes/query/no), and > - one for the export mode (yes/no, and maybe query as well?). > Agreed, The eval header argument now supports the following four options (updated in the manual under "Specific header arguments"). | no or never | no evaluation anytime | | query | query before evaluation anytime | | no-eval or never-eval | no evaluation during export | | query-eval| query before evaluation during export | Thanks for the suggestion -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Eric, Eric Schulte wrote: > Torsten Anders writes: >> 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. It certainly is a good addition, but wouldn't it be better to add an orthogonal argument for the "exports" stuff, that is a second parameter? I mean: you've added `non-export' which maps to: - `yes' for interactive evaluation - `never' for export I'm sure a guy (or a woman) will ask in a short future for: - `query' for interactive evaluation - `never' for export. Hence, maybe we should be able to set 2 possible behaviors[1] for the `eval' parameter: - one for the interactive mode (yes/query/no), and - one for the export mode (yes/no, and maybe query as well?). Best regards, Seb Footnotes: [1] Like for results, where we can give up to 3 options: `:results output scalar raw' -- Sebastien Vauban
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Torsten, Torsten Anders 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/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
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 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. Anyway, thanks a lot for your feedback. Best wishes, Torsten
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
"Sebastien Vauban" writes: > Hi Torsten, > > Torsten Anders wrote: >> Dear Org-Babel developers, >> >> When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the >> code blocks of at least some languages are executed during the export >> process. (Has this always been like that, I noticed this for the first >> time?) >> >> I would like to switch that off completely. I prefer evaluating code blocks >> individually to check their results. Also, many of by code blocks run >> substantial programs which slow down the export process considerably. >> >> I could not find an option to switch this off in the documentation. >> Apologies if I missed something obvious. I assume it is there somewhere, but >> I could not find it. > > #+PROPERTY: eval never > > does inhibit evaluation of the code blocks. > You could also look into using the ":cache" header argument to only re-run code blocks when their inputs have changed, or sometimes I find it easy to simply disassociate the results of a code block from the code block itself (e.g., through a rename), and then change the export property of the code block to either "code" or "none". Best -- Eric > > Best regards, > Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Torsten, Torsten Anders wrote: > Dear Org-Babel developers, > > When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the > code blocks of at least some languages are executed during the export > process. (Has this always been like that, I noticed this for the first > time?) > > I would like to switch that off completely. I prefer evaluating code blocks > individually to check their results. Also, many of by code blocks run > substantial programs which slow down the export process considerably. > > I could not find an option to switch this off in the documentation. > Apologies if I missed something obvious. I assume it is there somewhere, but > I could not find it. #+PROPERTY: eval never does inhibit evaluation of the code blocks. Best regards, Seb -- Sebastien Vauban
[O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Dear Org-Babel developers, When I am exporting an *.org buffer to, say, HTML or PDF (via Latex) the code blocks of at least some languages are executed during the export process. (Has this always been like that, I noticed this for the first time?) I would like to switch that off completely. I prefer evaluating code blocks individually to check their results. Also, many of by code blocks run substantial programs which slow down the export process considerably. I could not find an option to switch this off in the documentation. Apologies if I missed something obvious. I assume it is there somewhere, but I could not find it. Thank you! Best wishes, Torsten -- Dr Torsten Anders Course Leader, Music Technology University of Bedfordshire Park Square, Room A315 torsten.and...@beds.ac.uk http://strasheela.sourceforge.net http://www.torsten-anders.de
