* [org-babel] switching off (re-)evaluation of code blocks during Org export
@ 2011-11-21 16:37 Torsten Anders
2011-11-21 17:26 ` Sebastien Vauban
0 siblings, 1 reply; 12+ messages in thread
From: Torsten Anders @ 2011-11-21 16:37 UTC (permalink / raw)
To: Org-mode
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.anders@beds.ac.uk
http://strasheela.sourceforge.net
http://www.torsten-anders.de
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-21 16:37 Torsten Anders
@ 2011-11-21 17:26 ` Sebastien Vauban
2011-11-21 17:34 ` Eric Schulte
0 siblings, 1 reply; 12+ messages in thread
From: Sebastien Vauban @ 2011-11-21 17:26 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-21 17:26 ` Sebastien Vauban
@ 2011-11-21 17:34 ` Eric Schulte
0 siblings, 0 replies; 12+ messages in thread
From: Eric Schulte @ 2011-11-21 17:34 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
"Sebastien Vauban" <wxhgmqzgwmuf@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
@ 2011-11-22 0:13 Torsten Anders
2011-11-22 1:23 ` Eric Schulte
0 siblings, 1 reply; 12+ messages in thread
From: Torsten Anders @ 2011-11-22 0:13 UTC (permalink / raw)
To: Org-mode
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-22 0:13 [org-babel] switching off (re-)evaluation of code blocks during Org export Torsten Anders
@ 2011-11-22 1:23 ` Eric Schulte
2011-11-22 9:46 ` Sebastien Vauban
2011-11-27 20:12 ` Torsten Anders
0 siblings, 2 replies; 12+ messages in thread
From: Eric Schulte @ 2011-11-22 1:23 UTC (permalink / raw)
To: Torsten Anders; +Cc: Org-mode
Hi Torsten,
Torsten Anders <torsten.anders@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-22 1:23 ` Eric Schulte
@ 2011-11-22 9:46 ` Sebastien Vauban
2011-11-22 14:02 ` Eric Schulte
2011-11-27 20:12 ` Torsten Anders
1 sibling, 1 reply; 12+ messages in thread
From: Sebastien Vauban @ 2011-11-22 9:46 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
Hi Eric,
Eric Schulte wrote:
> Torsten Anders <torsten.anders-nRKTKYnHphK1Qrn1Bg8BZw@public.gmane.org> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-22 9:46 ` Sebastien Vauban
@ 2011-11-22 14:02 ` Eric Schulte
2011-11-22 17:15 ` Bernt Hansen
0 siblings, 1 reply; 12+ messages in thread
From: Eric Schulte @ 2011-11-22 14:02 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
>
> 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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-22 14:02 ` Eric Schulte
@ 2011-11-22 17:15 ` Bernt Hansen
2011-11-22 17:31 ` Eric Schulte
0 siblings, 1 reply; 12+ messages in thread
From: Bernt Hansen @ 2011-11-22 17:15 UTC (permalink / raw)
To: Eric Schulte; +Cc: Sebastien Vauban, emacs-orgmode
Eric Schulte <schulte.eric@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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-22 17:15 ` Bernt Hansen
@ 2011-11-22 17:31 ` Eric Schulte
0 siblings, 0 replies; 12+ messages in thread
From: Eric Schulte @ 2011-11-22 17:31 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Sebastien Vauban, emacs-orgmode
Bernt Hansen <bernt@norang.ca> writes:
> Eric Schulte <schulte.eric@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-22 1:23 ` Eric Schulte
2011-11-22 9:46 ` Sebastien Vauban
@ 2011-11-27 20:12 ` Torsten Anders
2011-11-28 7:13 ` Eric Schulte
1 sibling, 1 reply; 12+ messages in thread
From: Torsten Anders @ 2011-11-27 20:12 UTC (permalink / raw)
To: Eric Schulte; +Cc: Org-mode
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.anders@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-27 20:12 ` Torsten Anders
@ 2011-11-28 7:13 ` Eric Schulte
2011-11-28 10:01 ` Torsten Anders
0 siblings, 1 reply; 12+ messages in thread
From: Eric Schulte @ 2011-11-28 7:13 UTC (permalink / raw)
To: Torsten Anders; +Cc: Org-mode
Hi Torsten,
Change "non-export" to "no-export", see the manual for valid values for
the eval header argument.
Best -- Eric
Torsten Anders <torsten.anders@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.anders@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [org-babel] switching off (re-)evaluation of code blocks during Org export
2011-11-28 7:13 ` Eric Schulte
@ 2011-11-28 10:01 ` Torsten Anders
0 siblings, 0 replies; 12+ messages in thread
From: Torsten Anders @ 2011-11-28 10:01 UTC (permalink / raw)
To: Eric Schulte; +Cc: Org-mode
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.anders@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.anders@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/
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-11-28 10:04 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-22 0:13 [org-babel] switching off (re-)evaluation of code blocks during Org export Torsten Anders
2011-11-22 1:23 ` Eric Schulte
2011-11-22 9:46 ` Sebastien Vauban
2011-11-22 14:02 ` Eric Schulte
2011-11-22 17:15 ` Bernt Hansen
2011-11-22 17:31 ` Eric Schulte
2011-11-27 20:12 ` Torsten Anders
2011-11-28 7:13 ` Eric Schulte
2011-11-28 10:01 ` Torsten Anders
-- strict thread matches above, loose matches on Subject: below --
2011-11-21 16:37 Torsten Anders
2011-11-21 17:26 ` Sebastien Vauban
2011-11-21 17:34 ` Eric Schulte
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).