From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: [Bug] [babel] calls in :noexport: subtrees evaluated Date: Wed, 05 Sep 2012 20:53:23 +0200 Message-ID: <87a9x4cndo.fsf@med.uni-goettingen.de> References: <87ipbtc5q0.fsf@med.uni-goettingen.de> <80y5ko3cko.fsf@somewhere.org> <87zk54ejc4.fsf@gmail.com> <80zk541m1j.fsf@somewhere.org> <87r4qgqr2i.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:57050) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9KjK-0000BL-Fo for emacs-orgmode@gnu.org; Wed, 05 Sep 2012 14:53:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9KjI-00006L-UO for emacs-orgmode@gnu.org; Wed, 05 Sep 2012 14:53:38 -0400 Received: from plane.gmane.org ([80.91.229.3]:59797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9KjI-00006H-NN for emacs-orgmode@gnu.org; Wed, 05 Sep 2012 14:53:36 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T9KjI-0002Qa-BO for emacs-orgmode@gnu.org; Wed, 05 Sep 2012 20:53:36 +0200 Received: from vpn-2105.gwdg.de ([134.76.2.105]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2012 20:53:36 +0200 Received: from andreas.leha by vpn-2105.gwdg.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Sep 2012 20:53:36 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Eric Schulte writes: > "Sebastien Vauban" writes: > >> Hi Nicolas, >> >> Nicolas Goaziou wrote: >>> "Sebastien Vauban" writes: >>>> In fact, what you expect is that putting a tag ":noexport:" on a subtree would >>>> propagate the option ":eval no-export"[1] to all code blocks beneath it. That's >>>> the one which inhibits code block evaluation during export (but allow >>>> interactive evaluation). >>>> >>>> I really don't have any strong opinion about this, even if, without further >>>> thinking, I'd favor the same behavior as the one you expected. >>> >>> To answer the OP, :noexport: tag is related to export, not to >>> src-blocks. There are already other ways to disable code evaluation on >>> subtrees. It may be useful, as in your case, to have their behaviour >>> linked, but again, sometimes not. >>> >>> It's often better to keep separate things, well, separate. >> >> To see whether there is more weigh toward a solution or the other, I would >> formulate the question this way: >> >> are there real use-cases where one would want to *not* export a subtree >> (by tagging it), though to *well* evaluate the code blocks it contains? >> > > #+Title: Example > > Results in heading [[#first]] are generated by un-exported code blocks in > heading [[#second]]. > > * first > :PROPERTIES: > :CUSTOM_ID: first > :END: > > Things my adviser cares about. > > #+RESULTS: foo > : like some result: 3 > > * second :noexport: > :PROPERTIES: > :CUSTOM_ID: second > :END: > > Things my adviser does not care about, but which I need to keep, like > minutiae of generating the result. > > #+Name: bar > - foo > - bar > - baz > > #+Name: foo > #+begin_src sh :var bar=bar > echo "like some result: $(echo $bar|wc -w)" > #+end_src I see the use case in the example. It would have never occurred to me to write it like that, though. If I need the results in [[#first]] I'd always have an appropriate #+call line in [[#first]] as well... - Andreas