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

From: Andreas Leha <andreas.leha@med.uni-goettingen.de>
To: emacs-orgmode@gnu.org
Subject: Re: Re: disable automatic source block evaluation but allow manual
Date: Thu, 16 Dec 2010 14:48:28 +0100	[thread overview]
Message-ID: <4D0A18AC.5020002@med.uni-goettingen.de> (raw)
In-Reply-To: <807hfaaw14.fsf@missioncriticalit.com>

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