From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: Re: disable automatic source block evaluation but allow manual Date: Thu, 16 Dec 2010 15:08:25 +0100 Message-ID: <4D0A1D59.3080907@gmail.com> References: <4D09D2EF.8070309@med.uni-goettingen.de> <807hfaaw14.fsf@missioncriticalit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Return-path: Received: from [140.186.70.92] (port=39071 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PTEVT-00064N-2L for emacs-orgmode@gnu.org; Thu, 16 Dec 2010 09:08:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PTEVR-0007PO-Mi for emacs-orgmode@gnu.org; Thu, 16 Dec 2010 09:08:30 -0500 Received: from mail-wy0-f169.google.com ([74.125.82.169]:56658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PTEVR-0007PH-Ca for emacs-orgmode@gnu.org; Thu, 16 Dec 2010 09:08:29 -0500 Received: by wyj26 with SMTP id 26so2634629wyj.0 for ; Thu, 16 Dec 2010 06:08:28 -0800 (PST) In-Reply-To: <807hfaaw14.fsf@missioncriticalit.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: =?UTF-8?B?U8OpYmFzdGllbiBWYXViYW4=?= Cc: emacs-orgmode@gnu.org -----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-----