Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Torsten Anders]

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: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Eric Schulte]

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/

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Sebastien Vauban]

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

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Eric Schulte]

>
> 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: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Bernt Hansen]

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

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Eric Schulte]

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/

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Torsten Anders]

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/

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Eric Schulte]

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/

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Torsten Anders]

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/

[org-babel] switching off (re-)evaluation of code blocks during Org export

[Torsten Anders]

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

Re: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Sebastien Vauban]

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: [org-babel] switching off (re-)evaluation of code blocks during Org export

[Eric Schulte]

"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/