* 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: 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
* 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
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).