[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] Re: disable automatic source block evaluation but allow ma
From: |
Andreas Leha |
Subject: |
Re: [Orgmode] Re: disable automatic source block evaluation but allow manual |
Date: |
Thu, 16 Dec 2010 14:48:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101030 Iceowl/1.0b1 Icedove/3.0.10 |
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
smime.p7s
Description: S/MIME Cryptographic Signature