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 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/
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 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/
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 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/
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Hi Eric, Eric Schulte wrote: Torsten Anders torsten.and...@beds.ac.uk 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
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
Eric Schulte schulte.e...@gmail.com 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
Bernt Hansen be...@norang.ca writes: Eric Schulte schulte.e...@gmail.com 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
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
Re: [O] [org-babel] switching off (re-)evaluation of code blocks during Org export
Sebastien Vauban wxhgmqzgw...@spammotel.com 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
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
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/
