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

[Rainer M Krug <r.m.krug@gmail.com>]

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