* disable automatic source block evaluation but allow manual
@ 2010-12-16 8:50 Andreas Leha
2010-12-16 9:48 ` Sébastien Vauban
2010-12-16 13:23 ` Eric Schulte
0 siblings, 2 replies; 8+ messages in thread
From: Andreas Leha @ 2010-12-16 8:50 UTC (permalink / raw)
To: emacs-orgmode
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: disable automatic source block evaluation but allow manual
2010-12-16 8:50 disable automatic source block evaluation but allow manual Andreas Leha
@ 2010-12-16 9:48 ` Sébastien Vauban
2010-12-16 13:48 ` Andreas Leha
2010-12-16 14:08 ` Rainer M Krug
2010-12-16 13:23 ` Eric Schulte
1 sibling, 2 replies; 8+ messages in thread
From: Sébastien Vauban @ 2010-12-16 9:48 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: disable automatic source block evaluation but allow manual
2010-12-16 8:50 disable automatic source block evaluation but allow manual Andreas Leha
2010-12-16 9:48 ` Sébastien Vauban
@ 2010-12-16 13:23 ` Eric Schulte
1 sibling, 0 replies; 8+ messages in thread
From: Eric Schulte @ 2010-12-16 13:23 UTC (permalink / raw)
To: Andreas Leha; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: disable automatic source block evaluation but allow manual
2010-12-16 9:48 ` Sébastien Vauban
@ 2010-12-16 13:48 ` Andreas Leha
2010-12-16 14:08 ` Rainer M Krug
1 sibling, 0 replies; 8+ messages in thread
From: Andreas Leha @ 2010-12-16 13:48 UTC (permalink / raw)
To: emacs-orgmode
[-- 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: disable automatic source block evaluation but allow manual
2010-12-16 9:48 ` Sébastien Vauban
2010-12-16 13:48 ` Andreas Leha
@ 2010-12-16 14:08 ` Rainer M Krug
2010-12-16 14:16 ` Eric Schulte
2010-12-16 14:43 ` Sébastien Vauban
1 sibling, 2 replies; 8+ messages in thread
From: Rainer M Krug @ 2010-12-16 14:08 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
-----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-----
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: disable automatic source block evaluation but allow manual
2010-12-16 14:08 ` Rainer M Krug
@ 2010-12-16 14:16 ` Eric Schulte
2010-12-16 14:43 ` Sébastien Vauban
1 sibling, 0 replies; 8+ messages in thread
From: Eric Schulte @ 2010-12-16 14:16 UTC (permalink / raw)
To: Rainer M Krug; +Cc: Sébastien Vauban, emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: disable automatic source block evaluation but allow manual
2010-12-16 14:08 ` Rainer M Krug
2010-12-16 14:16 ` Eric Schulte
@ 2010-12-16 14:43 ` Sébastien Vauban
2010-12-16 14:54 ` Eric Schulte
1 sibling, 1 reply; 8+ messages in thread
From: Sébastien Vauban @ 2010-12-16 14:43 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Re: disable automatic source block evaluation but allow manual
2010-12-16 14:43 ` Sébastien Vauban
@ 2010-12-16 14:54 ` Eric Schulte
0 siblings, 0 replies; 8+ messages in thread
From: Eric Schulte @ 2010-12-16 14:54 UTC (permalink / raw)
To: Sébastien Vauban; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-12-16 14:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-16 8:50 disable automatic source block evaluation but allow manual Andreas Leha
2010-12-16 9:48 ` Sébastien Vauban
2010-12-16 13:48 ` Andreas Leha
2010-12-16 14:08 ` Rainer M Krug
2010-12-16 14:16 ` Eric Schulte
2010-12-16 14:43 ` Sébastien Vauban
2010-12-16 14:54 ` Eric Schulte
2010-12-16 13:23 ` Eric Schulte
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).