disable automatic source block evaluation but allow manual

disable automatic source block evaluation but allow manual

[Andreas Leha]

[-- Attachment #1.1: Type: text/plain, Size: 377 bytes --]

Hi all,

is there an option (source block header argument) that allows to disable
the evaluation of the block, but still allows C-c C-c to perform the
evaluation?
The header argument ':eval never' disables the evaluation completely.
I'd like the C-c C-c to take precedence over this.

So I guess I am looking for something like ':eval manual'

Regards,
Andreas



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6432 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: disable automatic source block evaluation but allow manual

[Sébastien Vauban]

Hi Andreas,

Andreas Leha wrote:
> is there an option (source block header argument) that allows to disable the
> evaluation of the block, but still allows C-c C-c to perform the evaluation?
> The header argument ':eval never' disables the evaluation completely. I'd
> like the C-c C-c to take precedence over this.
>
> So I guess I am looking for something like ':eval manual'

If I rewrite what I understood from your post, you want to make a clear
distinction between:

- allowing evaluation in the Org buffer (when *editing*)
- allowing evaluation when *exporting* it

In fact, I've been thinking at something that annoys me a bit, around this
similar subject: I find it weird to have a buffer that does not contain the
same up-to-date information as the exported (and updated) document.

Arbitrary example:

--8<---------------cut here---------------start------------->8---
* Sh code

#+begin_src sh :results output :exports both
date
#+end_src

#+results:
: Thu, Dec 16, 2010 10:32:36 AM

#+begin_src sh :var thisfile=(buffer-file-name)
echo $(ls -lia "$thisfile" | cut -d " " -f 6) "Bytes in this buffer"
#+end_src

#+results:
: 297 Bytes in this buffer
--8<---------------cut here---------------end--------------->8---

If I add words in that file, the number of characters will go up. That will be
correctly "visible" (shown) in the exported document.

But, *if I don't manually execute* all the code snippets above, they will have
a wrong output...[1]

... moreover, as said previously, it will always (in the above example) be
different from the HTML/PDF version of that buffer. It may lead to erroneous
appreciation of code results, and lead to different and unsynchronized
versions of documents (source Org file, exported documents).

I have a gut feeling that either:

- the export function should not evaluate any code block, or

- when evaluating them for the export, the Org buffer should be updated in the
  same way (results of evaluation copied back into the Org buffer).

I guess the first solution is not a good one. What about the second?

Best regards,
  Seb

Footnotes:
[1] Number of characters won't reflect the new values. And, even if I don't
touch it, the time information will be different between the Org and the
exported files.
-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: disable automatic source block evaluation but allow manual

[Eric Schulte]

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> Hi all,
>
> is there an option (source block header argument) that allows to disable
> the evaluation of the block, but still allows C-c C-c to perform the
> evaluation?
> The header argument ':eval never' disables the evaluation completely.
> I'd like the C-c C-c to take precedence over this.
>
> So I guess I am looking for something like ':eval manual'
>

':eval query' should do the trick.

http://orgmode.org/manual/eval.html#eval

Best -- Eric

> Regards,
> Andreas
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: disable automatic source block evaluation but allow manual

[Andreas Leha]

[-- Attachment #1.1: Type: text/plain, Size: 3840 bytes --]

Hi all,

hi Sébastien, thanks for your answer, which adds much more in-depth
information to my problem.  In fact, what you describe is probably the
bigger problem.

But for me (maybe I am the only one ...) it would be handy to have
source blocks, that are evaluated on C-c C-c *only*.  That also means
that when evaluating the whole buffer or subtree, these blocks should
not be evaluated.

The reason is that I have a lot of blocks of R code, that are only used
internally.  When I evaluate them they "spoil" my workspace, so that
evaluation is disabled for export and also when the whole program/buffer
is evaluated.  But for testing/debugging it is often handy to evaluate
one of them anyway.  Since there are simple work arounds (e.g. copy the
source block to the R session), it is not a vital functionality.

Regards,
Andreas


Am 16.12.2010 10:48, schrieb Sébastien Vauban:
> Hi Andreas,
>
> Andreas Leha wrote:
>   
>> is there an option (source block header argument) that allows to disable the
>> evaluation of the block, but still allows C-c C-c to perform the evaluation?
>> The header argument ':eval never' disables the evaluation completely. I'd
>> like the C-c C-c to take precedence over this.
>>
>> So I guess I am looking for something like ':eval manual'
>>     
> If I rewrite what I understood from your post, you want to make a clear
> distinction between:
>
> - allowing evaluation in the Org buffer (when *editing*)
> - allowing evaluation when *exporting* it
>
> In fact, I've been thinking at something that annoys me a bit, around this
> similar subject: I find it weird to have a buffer that does not contain the
> same up-to-date information as the exported (and updated) document.
>
> Arbitrary example:
>
> --8<---------------cut here---------------start------------->8---
> * Sh code
>
> #+begin_src sh :results output :exports both
> date
> #+end_src
>
> #+results:
> : Thu, Dec 16, 2010 10:32:36 AM
>
> #+begin_src sh :var thisfile=(buffer-file-name)
> echo $(ls -lia "$thisfile" | cut -d " " -f 6) "Bytes in this buffer"
> #+end_src
>
> #+results:
> : 297 Bytes in this buffer
> --8<---------------cut here---------------end--------------->8---
>
> If I add words in that file, the number of characters will go up. That will be
> correctly "visible" (shown) in the exported document.
>
> But, *if I don't manually execute* all the code snippets above, they will have
> a wrong output...[1]
>
> ... moreover, as said previously, it will always (in the above example) be
> different from the HTML/PDF version of that buffer. It may lead to erroneous
> appreciation of code results, and lead to different and unsynchronized
> versions of documents (source Org file, exported documents).
>
> I have a gut feeling that either:
>
> - the export function should not evaluate any code block, or
>
> - when evaluating them for the export, the Org buffer should be updated in the
>   same way (results of evaluation copied back into the Org buffer).
>
> I guess the first solution is not a good one. What about the second?
>
> Best regards,
>   Seb
>
> Footnotes:
> [1] Number of characters won't reflect the new values. And, even if I don't
> touch it, the time information will be different between the Org and the
> exported files.
>   

-- 
Andreas Leha

Universitätsmedizin Göttingen
Abteilung Medizinische Statistik
Humboldtallee 32
37073 Göttingen

Tel: +49 (0)551 39-10710
Fax: +49 (0)551 39-4995

http://www.ams.med.uni-goettingen.de/amsneu/leha.html



University Medical Center Göttingen
Department for Medical Statistics
Humboldtallee 32
37073 Göttingen
Germany

Phone: +49 (0) 551 39-10710
Fax: +49 (0) 551 39-4995

http://www.ams.med.uni-goettingen.de/amsneu/leha-en.html



[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 6432 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: disable automatic source block evaluation but allow manual

[Rainer M Krug]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2010 10:48 AM, Sébastien Vauban wrote:
> Hi Andreas,
> 
> Andreas Leha wrote:
>> is there an option (source block header argument) that allows to disable the
>> evaluation of the block, but still allows C-c C-c to perform the evaluation?
>> The header argument ':eval never' disables the evaluation completely. I'd
>> like the C-c C-c to take precedence over this.
>>
>> So I guess I am looking for something like ':eval manual'
> 
> If I rewrite what I understood from your post, you want to make a clear
> distinction between:
> 
> - allowing evaluation in the Org buffer (when *editing*)
> - allowing evaluation when *exporting* it
> 
> In fact, I've been thinking at something that annoys me a bit, around this
> similar subject: I find it weird to have a buffer that does not contain the
> same up-to-date information as the exported (and updated) document.
> 
> Arbitrary example:
> 
> --8<---------------cut here---------------start------------->8---
> * Sh code
> 
> #+begin_src sh :results output :exports both
> date
> #+end_src
> 
> #+results:
> : Thu, Dec 16, 2010 10:32:36 AM
> 
> #+begin_src sh :var thisfile=(buffer-file-name)
> echo $(ls -lia "$thisfile" | cut -d " " -f 6) "Bytes in this buffer"
> #+end_src
> 
> #+results:
> : 297 Bytes in this buffer
> --8<---------------cut here---------------end--------------->8---
> 
> If I add words in that file, the number of characters will go up. That will be
> correctly "visible" (shown) in the exported document.
> 
> But, *if I don't manually execute* all the code snippets above, they will have
> a wrong output...[1]
> 
> ... moreover, as said previously, it will always (in the above example) be
> different from the HTML/PDF version of that buffer. It may lead to erroneous
> appreciation of code results, and lead to different and unsynchronized
> versions of documents (source Org file, exported documents).

Here the distinction (or view) of what the org file is comes in: as you
see it, the org-file is a *usable result* in itself and already the
*final product*. Then, it *has* to reflect (and be identical to) the
exported one.

If, on the other hand, I see the org file as a *source*, equivalent to
source code, the final product is what I get when I export (or compile)
- - then it is irrelevant if the results in the org file are up to date or
not - they could be seen as an *illustration* or an *example* on how the
final results will look. This is how I see it.

But I can completely understand, why you would like to have your
org-file as an up-to-date document in its own right.

I guess one possibility would be to have a header argument
(update-results-when-exporting) which, if set, would update all results
in the org buffer and export then.

I for myself actually only use the C-c with the results block for
testing, and the final evaluation is done in the export.

Cheers,

Rainer


> 
> I have a gut feeling that either:
> 
> - the export function should not evaluate any code block, or
> 
> - when evaluating them for the export, the Org buffer should be updated in the
>   same way (results of evaluation copied back into the Org buffer).
> 
> I guess the first solution is not a good one. What about the second?
> 
> Best regards,
>   Seb
> 
> Footnotes:
> [1] Number of characters won't reflect the new values. And, even if I don't
> touch it, the time information will be different between the Org and the
> exported files.


- -- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Tel:        +33 - (0)9 53 10 27 44
Cell:       +27 - (0)8 39 47 90 42
Fax (SA):   +27 - (0)8 65 16 27 82
Fax (D) :   +49 - (0)3 21 21 25 22 44
Fax (FR):   +33 - (0)9 58 10 27 44
email:      Rainer@krugs.de

Skype:      RMkrug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0KHVkACgkQoYgNqgF2egp14ACcD/pWZAUaYYyjYUKip3Mx/Hb1
+UIAnjk5nIB6aSwNpqNoTF501DlKVZDd
=wp+6
-----END PGP SIGNATURE-----

Re: Re: disable automatic source block evaluation but allow manual

[Eric Schulte]

Rainer M Krug <r.m.krug@gmail.com> writes:

>
> I guess one possibility would be to have a header argument
> (update-results-when-exporting) which, if set, would update all results
> in the org buffer and export then.
>

This can also be accomplished using an export hook.  e.g.

(add-hook 'org-export-first-hook 'org-babel-execute-buffer)

Best -- Eric

Re: disable automatic source block evaluation but allow manual

[Sébastien Vauban]

Hi Rainer and Eric,

Rainer M Krug wrote:
>> Here the distinction (or view) of what the org file is comes in: as you see
>> it, the org-file is a *usable result* in itself and already the *final
>> product*. Then, it *has* to reflect (and be identical to) the exported one.
>>
>> If, on the other hand, I see the org file as a *source*, equivalent to
>> source code, the final product is what I get when I export (or compile)
>> - then it is irrelevant if the results in the org file are up to date or
>> not - they could be seen as an *illustration* or an *example* on how the
>> final results will look. This is how I see it.
>>
>> But I can completely understand, why you would like to have your org-file
>> as an up-to-date document in its own right.

Yes, I view the Org as a result per se. "In situ execution" makes me think
that way: I always see the results blocks in the Org itself, and almost always
export "both" (the code and the results).


>> I guess one possibility would be to have a header argument
>> (update-results-when-exporting) which, if set, would update all results
>> in the org buffer and export then.
>
> This can also be accomplished using an export hook.  e.g.
>
> (add-hook 'org-export-first-hook 'org-babel-execute-buffer)

Thanks Eric for this. Though it is not yet *exactly* what I meant: here,
buffer is executed twice, once just before exporting (thru the hook) and once
when exporting.

Hence:

- The results still may defer: date example that I gave previously in this
  thread, but as well results of SQL code execution that would have
  side-effects, etc... Not completely in sync'.

- Regarding performance, it consumes twice as much time...

Would it be possible, then, to avoid executing the buffer when exporting (only
keeping it, once, in the export hook)?

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: disable automatic source block evaluation but allow manual

[Eric Schulte]

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

>>> I guess one possibility would be to have a header argument
>>> (update-results-when-exporting) which, if set, would update all results
>>> in the org buffer and export then.
>>
>> This can also be accomplished using an export hook.  e.g.
>>
>> 
>
> Thanks Eric for this. Though it is not yet *exactly* what I meant: here,
> buffer is executed twice, once just before exporting (thru the hook) and once
> when exporting.
>
> Hence:
>
> - The results still may defer: date example that I gave previously in this
>   thread, but as well results of SQL code execution that would have
>   side-effects, etc... Not completely in sync'.
>
> - Regarding performance, it consumes twice as much time...
>
> Would it be possible, then, to avoid executing the buffer when exporting (only
> keeping it, once, in the export hook)?

Yes, this should be possible through setting the :cache header argument
on a buffer-wide basis, and calling `org-babel-execute-buffer' with a
prefix argument (which forces re-evaluation in the face of caching).

(add-hook 'org-export-first-hook (lambda () (org-babel-execute-buffer t)))

Best -- Eric