From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ken Mankoff <mankoff@gmail.com>
Subject: Re: Babel should not work in the subtree marked as not exported
Date: Tue, 11 Mar 2014 09:57:49 -0400
Message-ID: <m2wqg0bzxe.fsf@gorgonzola.whoi.edu>
References: <87wqg0gawq.fsf@gmail.com> <m2y50gc1b6.fsf@gorgonzola.whoi.edu>
	<87lhwgettp.fsf@med.uni-goettingen.de>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46373)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mankoff@gmail.com>) id 1WNNBx-0007t9-1l
	for emacs-orgmode@gnu.org; Tue, 11 Mar 2014 09:58:09 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mankoff@gmail.com>) id 1WNNBo-0002rP-KJ
	for emacs-orgmode@gnu.org; Tue, 11 Mar 2014 09:58:00 -0400
Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]:35046)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mankoff@gmail.com>) id 1WNNBo-0002rK-FB
	for emacs-orgmode@gnu.org; Tue, 11 Mar 2014 09:57:52 -0400
Received: by mail-ie0-f175.google.com with SMTP id to1so8831899ieb.34
	for <emacs-orgmode@gnu.org>; Tue, 11 Mar 2014 06:57:51 -0700 (PDT)
In-reply-to: <87lhwgettp.fsf@med.uni-goettingen.de>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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: Andreas Leha <andreas.leha@med.uni-goettingen.de>
Cc: emacs-orgmode@gnu.org

Hi Andreas,

On 2014-03-11 at 09:41, Andreas Leha wrote:
> Hi Ken,
>
> Ken Mankoff <mankoff@gmail.com> writes:
>
>> On 2014-03-11 at 08:47, zwz wrote:
>>> In my setup, there is 
>>> (setq org-export-exclude-tags '("private" "exclude")
>>>
>>> and In my test.org:
>>>
>>> * test
>>>
>>> ** Not exported                :exclude:
>>>    #+BEGIN_SRC ditaa :file test.png :cmdline -E
>>>           +--------+---+---+---+---+---+---+---+  +---+---+---+---+---+---+---+---+
>>>       x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 |
>>>           +--------+---+---+---+---+---+---+---+  +---+---+---+---+---+---+---+---+
>>>    #+END_SRC
>>>
>>> ** blah blah
>>>    blah blah blah
>>>
>>>
>>> When I try to export it to pdf, the test.png is still generated,
>>> although it is not used for the pdf at all.
>>> So I think the export procedure may be optimized for more efficiency.
>>
>> No, because I often have code and sections I don't want exported, but
>> I want their side-effects active. For example, code with sessions
>> where part is not exported, but I need that code run so code
>> elsewhere, using the same session, is able to run and be exported.
>>
>>   -k.
>
>
> So what is your suggestion for the OP to achieve what he is after?
> noexport and noeval at the same time.
>

I do not have a suggestion. I'm not very familiar with the various
options, and didn't know noeval exists. That sounds like a good
solution. The OP suggestion of "may be optimized" is vague, but I took
it, perhaps incorrectly, to mean "don't run code in noexport
sections", hence my disagreement.

  -k.