Re: [O] Babel should not work in the subtree marked as not exported

2014-03-24 Thread Nicolas Goaziou
Hello,

Eric Schulte schulte.e...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 As a side note, I think `org-babel-under-commented-heading-p' is useful
 enough (with an optional parameter to prevent inheritance, maybe) to be
 moved into org.el.


 I agree.

Here is the patch.


Regards,

-- 
Nicolas Goaziou
From 690543c40d766802df3e30e44ef7d6f04d6c18ba Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Mon, 24 Mar 2014 16:12:12 +0100
Subject: [PATCH] Rename `org-babel-under-commented-heading-p'

* lisp/org.el (org-in-commented-heading-p): New function.
* lisp/ob-tangle.el (org-babel-under-commented-heading-p): Remove
  function.
(org-babel-tangle-collect-blocks): Use new function.
* lisp/ob-exp.el (org-babel-exp-process-buffer): Use new function.

* testing/lisp/test-org.el (test-org/in-commented-heading-p): New
  test.
---
 lisp/ob-exp.el   |  2 +-
 lisp/ob-tangle.el| 18 +-
 lisp/org.el  | 16 
 testing/lisp/test-org.el | 32 
 4 files changed, 50 insertions(+), 18 deletions(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 0ddb4dc..3b63422 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -158,7 +158,7 @@ may make them unreachable.
 			^[ \t]*#\\+BEGIN_SRC)))
 	(goto-char (point-min))
 	(while (re-search-forward regexp nil t)
-	  (unless (save-match-data (org-babel-under-commented-heading-p))
+	  (unless (save-match-data (org-in-commented-heading-p))
 	(let* ((element (save-excursion
 			  ;; If match is inline, point is at its
 			  ;; end.  Move backward so
diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index bf67410..294a6ff 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -357,22 +357,6 @@ that the appropriate major-mode is set.  SPEC has the form:
insert-comment
(org-fill-template org-babel-tangle-comment-format-end link-data)
 
-(defvar org-comment-string) ;; Defined in org.el
-(defun org-babel-under-commented-heading-p ()
-  Non-nil if point is under a commented heading.
-This function also checks ancestors of the current headline, if
-any.
-  (cond
-   ((org-before-first-heading-p) nil)
-   ((let ((headline (nth 4 (org-heading-components
-  (and headline
-	   (let ((case-fold-search nil))
-	 (org-string-match-p (concat ^ org-comment-string \\(?: \\|$\\))
- headline)
-   (t (save-excursion
-	(and (org-up-heading-safe)
-	 (org-babel-under-commented-heading-p))
-
 (defun org-babel-tangle-collect-blocks (optional language tangle-file)
   Collect source blocks in the current Org-mode file.
 Return an association list of source-code block specifications of
@@ -396,7 +380,7 @@ can be used to limit the collected code blocks by target file.
   (let* ((info (org-babel-get-src-block-info 'light))
 	 (src-lang (nth 0 info))
 	 (src-tfile (cdr (assoc :tangle (nth 2 info)
-(unless (or (org-babel-under-commented-heading-p)
+(unless (or (org-in-commented-heading-p)
 		(string= (cdr (assoc :tangle (nth 2 info))) no)
 		(and tangle-file (not (equal tangle-file src-tfile
   (unless (and language (not (string= language src-lang)))
diff --git a/lisp/org.el b/lisp/org.el
index 727f646..ef0bc3f 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -23303,6 +23303,22 @@ This version does not only check the character property, but also
 ;; Compatibility alias with Org versions  7.8.03
 (defalias 'org-on-heading-p 'org-at-heading-p)
 
+(defun org-in-commented-heading-p (optional no-inheritance)
+  Non-nil if point is under a commented heading.
+This function also checks ancestors of the current headline,
+unless optional argument NO-INHERITANCE is non-nil.
+  (cond
+   ((org-before-first-heading-p) nil)
+   ((let ((headline (nth 4 (org-heading-components
+  (and headline
+	   (let ((case-fold-search nil))
+	 (org-string-match-p (concat ^ org-comment-string \\(?: \\|$\\))
+ headline)
+   (no-inheritance nil)
+   (t (save-excursion
+	(and (org-up-heading-safe)
+	 (org-in-commented-heading-p t))
+
 (defun org-at-comment-p nil
   Is cursor in a line starting with a # character?
   (save-excursion
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 949392e..0144841 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -544,6 +544,38 @@
 
 
 
+;;; Headline
+
+(ert-deftest test-org/in-commented-heading-p ()
+  Test `org-in-commented-heading-p' specifications.
+  ;; Commented headline.
+  (should
+   (org-test-with-temp-text * COMMENT Headline\nBody
+ (goto-char (point-max))
+ (org-in-commented-heading-p)))
+  ;; Commented ancestor.
+  (should
+   (org-test-with-temp-text * COMMENT Headline\n** Level 2\nBody
+ (goto-char (point-max))
+ (org-in-commented-heading-p)))
+  ;; Comment keyword is case-sensitive.
+  (should-not
+   (org-test-with-temp-text * Comment Headline\nBody
+ (goto-char 

Re: [O] Babel should not work in the subtree marked as not exported

2014-03-24 Thread Eric Schulte
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Eric Schulte schulte.e...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 As a side note, I think `org-babel-under-commented-heading-p' is useful
 enough (with an optional parameter to prevent inheritance, maybe) to be
 moved into org.el.


 I agree.

 Here is the patch.


Looks good to me, I'll leave to Bastien since it touches core Org-mode
functionality and not just Babel.

Thanks,


-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-24 Thread Bastien
Hi Nicolas and Eric,

Eric Schulte schulte.e...@gmail.com writes:

 Looks good to me, I'll leave to Bastien since it touches core Org-mode
 functionality and not just Babel.

Looks good to me, please apply,

-- 
 Bastien



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-24 Thread Eric Schulte
Bastien b...@gnu.org writes:

 Hi Nicolas and Eric,

 Eric Schulte schulte.e...@gmail.com writes:

 Looks good to me, I'll leave to Bastien since it touches core Org-mode
 functionality and not just Babel.

 Looks good to me, please apply,

Applied.

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-24 Thread Samuel Wales
now that everybody is happy, agreeing, and singing in a circle holding
hands, i thought i'd stir the pot.  :]  i hope i don't get wicked
glares.  :]

there are a few unresolved questions.  there is also something that,
for my workflow at least, is a bug.

i set org-export-with-tasks to nil, because i want to export only
blank headers.  this is a GREAT feature.

tldr: call lines are executed when they should not be.

===

i never use export tags.  i only use comment for occasional,
temporary, truly commented out things.  i cannot use it for more
purposes because it changes sorting and highlighting of todo keywords.
 that makes it not worth using for any other purpose.

so i do:

===
* a
*** REF b
*** NEXT e
*** d
*** MAYBE c
===

which exports a and d, but not b e c.  this is perfect.  it is exactly
what i want.  i get a sense of this is software working the way it
should every time i export.  i REALLY like how i can intersperse
notes with exported stuff.  no tags or comments or anything fancy,
just todo keywords.

except for one thing.

underneath b i like to put babel blocks that are relevant to a.  and
above the babel blocks, i might have some call lines.  these lines are
for testing.  i do c-c c-c on them manually, to test the block.

i also export b while testing, to get all of them at once.  but most
of the time i only export a.

this is all well and good -- again, perfect -- but in maint at least,
babel actually executes those call lines upon export of a.

i don't want them exported, because they are only there for testing.
i don't want to comment out the header, because that changes font
lock, turns off the block [which i use], and changes sorting.

to me it's a bug that those call lines are executed.

i'll join the circle if you guys will agree with me on this.  :]

samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-24 Thread Samuel Wales
note: this is not a high priority for me, but it seems like a bug, it
can result in surprising behavior for new users, and it helps clarify
this thread, so it seemed worth posting.  the ecm is in this thread.



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-17 Thread Andreas Leha
Hi Nicolas and Eric,

Eric Schulte schulte.e...@gmail.com writes:

 Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Eric Schulte schulte.e...@gmail.com writes:

 This sounds like a good compromise to me.  As you say, this should
 easily and visually support both use cases and is intuitive.  I've not
 touched the export machinery myself, so I'll leave the implementation to
 Nicolas but I definitely support this approach.

 Here are the patches, with tests. I leave to someone else the
 documentation part in the manual.


 Applied with documentation.  Thanks,


Thank you very much!

- Andreas





Re: [O] Babel should not work in the subtree marked as not exported

2014-03-15 Thread zwz
Eric Schulte schulte.e...@gmail.com writes:

 Sorry for being unclear here.  I wanted to propose different
 behaviour for TAGs (lets say :noexport:) and the COMMENT keyword.
 I am perfectly fine with :noexport: only prohibiting export but
 still allowing evaluation.

 But I propose that COMMENT be more treated like a comment, so more
 like a shorthand for commenting out that subtree using '# '.
 That way, evaluation would be disabled.

 I see two benefits:
 1. It serves the use-case where one wants a subtree to be not
exported and not evaluated.
 2. It more resembles Orgs idea of comments.

 And since the other use case (no export but still evaluation) is
 still very well supported via :noexport: there would be not too
 much loss.

 (IIRC, the COMMENT keyword was close to removal from Orgs syntax
 recently.  So, why not add some real additional functionality to
 it?)

 WDYT?


 This sounds like a good compromise to me.  As you say, this should
 easily and visually support both use cases and is intuitive.  I've not
 touched the export machinery myself, so I'll leave the implementation to
 Nicolas but I definitely support this approach.

 Best,


COMMENT is a good proposal. However, for someone new to org-mode, it is
difficult to tell the subtle difference between COMMENT and :noexport:.

IMO, it is more intuitive that :noexport: prohibits *both* export and
evaluation, and if some code in a :noexport: subtree is to be evaluated,
then it should be named and called in some other place.




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-15 Thread Nicolas Goaziou
Hello,

Eric Schulte schulte.e...@gmail.com writes:

 This sounds like a good compromise to me.  As you say, this should
 easily and visually support both use cases and is intuitive.  I've not
 touched the export machinery myself, so I'll leave the implementation to
 Nicolas but I definitely support this approach.

Here are the patches, with tests. I leave to someone else the
documentation part in the manual.

As a side note, I think `org-babel-under-commented-heading-p' is useful
enough (with an optional parameter to prevent inheritance, maybe) to be
moved into org.el.


Regards,

-- 
Nicolas Goaziou
From dadb93605aaef5b77837227ddd18b6e2448a00f1 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Sat, 15 Mar 2014 15:32:59 +0100
Subject: [PATCH 1/2] ob-tangle: Fix `org-babel-under-commented-heading-p'

* lisp/ob-tangle.el (org-babel-under-commented-heading-p):
  `org-comment-string' is case sensitive and cannot be attached to
  other text.
---
 lisp/ob-tangle.el | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el
index 2910d7f..bf67410 100644
--- a/lisp/ob-tangle.el
+++ b/lisp/ob-tangle.el
@@ -359,12 +359,17 @@ that the appropriate major-mode is set.  SPEC has the form:
 
 (defvar org-comment-string) ;; Defined in org.el
 (defun org-babel-under-commented-heading-p ()
-  Return t if currently under a commented heading.
-  (unless (org-before-first-heading-p)
-(if (let ((hd (nth 4 (org-heading-components
-	  (and hd (string-match (concat ^ org-comment-string) hd)))
-	t
-  (save-excursion
+  Non-nil if point is under a commented heading.
+This function also checks ancestors of the current headline, if
+any.
+  (cond
+   ((org-before-first-heading-p) nil)
+   ((let ((headline (nth 4 (org-heading-components
+  (and headline
+	   (let ((case-fold-search nil))
+	 (org-string-match-p (concat ^ org-comment-string \\(?: \\|$\\))
+ headline)
+   (t (save-excursion
 	(and (org-up-heading-safe)
 	 (org-babel-under-commented-heading-p))
 
-- 
1.9.0

From fbb6fd01568a6cc25a7c8b06f0210dce1685742c Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@gmail.com
Date: Sat, 15 Mar 2014 09:34:05 +0100
Subject: [PATCH 2/2] ob-exp: During export ignore Babel code under commented
 headlines

* lisp/ob-exp.el (org-babel-exp-process-buffer): Skip code under
  a commented headline.
* testing/lisp/test-ob-exp.el (ob-export/export-under-commented-headline):
  New test.
---
 lisp/ob-exp.el  | 242 ++--
 testing/lisp/test-ob-exp.el |  50 +
 2 files changed, 172 insertions(+), 120 deletions(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index 09ae827..38618ee 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -163,127 +163,129 @@ this template.
 			^[ \t]*#\\+BEGIN_SRC)))
 	(goto-char (point-min))
 	(while (re-search-forward regexp nil t)
-	  (let* ((element (save-excursion
-			;; If match is inline, point is at its
-			;; end.  Move backward so
-			;; `org-element-context' can get the
-			;; object, not the following one.
-			(backward-char)
-			(save-match-data (org-element-context
-		 (type (org-element-type element))
-		 (begin (copy-marker (org-element-property :begin element)))
-		 (end (copy-marker
-		   (save-excursion
-			 (goto-char (org-element-property :end element))
-			 (skip-chars-backward  \r\t\n)
-			 (point)
-	(case type
-	  (inline-src-block
-	   (let* ((info (org-babel-parse-inline-src-block-match))
-		  (params (nth 2 info)))
-		 (setf (nth 1 info)
-		   (if (and (cdr (assoc :noweb params))
-(string= yes (cdr (assoc :noweb params
-			   (org-babel-expand-noweb-references
-			info (org-babel-exp-get-export-buffer))
-			 (nth 1 info)))
-		 (goto-char begin)
-		 (let ((replacement (org-babel-exp-do-export info 'inline)))
-		   (if (equal replacement )
-		   ;; Replacement code is empty: remove inline src
-		   ;; block, including extra white space that
-		   ;; might have been created when inserting
-		   ;; results.
-		   (delete-region begin
-  (progn (goto-char end)
-	 (skip-chars-forward  \t)
-	 (point)))
-		 ;; Otherwise: remove inline src block but
-		 ;; preserve following white spaces.  Then insert
-		 ;; value.
-		 (delete-region begin end)
-		 (insert replacement)
-	  ((babel-call inline-babel-call)
-	   (let* ((lob-info (org-babel-lob-get-info))
-		  (results
-		   (org-babel-exp-do-export
-			(list emacs-lisp results
-			  (apply #'org-babel-merge-params
- org-babel-default-header-args
- org-babel-default-lob-header-args
- (append
-  (org-babel-params-from-properties)
-  (list
-   (org-babel-parse-header-arguments
-	(org-no-properties
-	 (concat
-	  :var results=
-	  (mapconcat 'identity
-

Re: [O] Babel should not work in the subtree marked as not exported

2014-03-15 Thread Eric Schulte
Nicolas Goaziou n.goaz...@gmail.com writes:

 Hello,

 Eric Schulte schulte.e...@gmail.com writes:

 This sounds like a good compromise to me.  As you say, this should
 easily and visually support both use cases and is intuitive.  I've not
 touched the export machinery myself, so I'll leave the implementation to
 Nicolas but I definitely support this approach.

 Here are the patches, with tests. I leave to someone else the
 documentation part in the manual.


Applied with documentation.  Thanks,


 As a side note, I think `org-babel-under-commented-heading-p' is useful
 enough (with an optional parameter to prevent inheritance, maybe) to be
 moved into org.el.


I agree.

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-14 Thread Sebastien Vauban
Andreas Leha wrote:
 Just to confirm.  This is what you suggest, correct?

 * test

 ** Not exported  
 :noexport:
:PROPERTIES:
:noeval: yes
:export: none
:END:

Maybe it's not a real problem, but quotes are for sure not necessarily:

--8---cut here---start-8---
  ** Not exported  
:noexport:
 :PROPERTIES:
 :noeval: yes
 :export: none
 :END:
--8---cut here---end---8---

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-14 Thread Andreas Leha
Hi Eric,

Eric Schulte schulte.e...@gmail.com writes:

 Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Eric,

 Eric Schulte schulte.e...@gmail.com writes:


 So what is your suggestion for the OP to achieve what he is after?
 noexport and noeval at the same time.


 I'm jumping in half way through here,

 Thanks for jumping in.

 but wouldn't setting the :noeval
 property to yes and :export property to none on the subtree work?

 Well, the property-setting works, but that is really cumbersome.  In a
 typical org file, it takes 5 keystrokes to toggle the :noexport: tag
 (C-c C-c n TAB RET).  But I do not want to count the keystrokes it take
 to additionally set these properties.


 Not that bad C-c C-x p n RET yes, I get 8 to set noeval, if you've
 done it already in that Org file.  You could also easily wrap this
 behavior into a function and bind that to a key-chord.


Plus setting :noexport: or COMMENT ;-)

Well, the most serious downside is, that there is no visual
feedback here.  So, if I want both export and evaluation to be
disabled for a subtree, I first need to remember to also set the
property.  And coming back later to that file, I also need to
check the property of each subtree in question to see, whether
evaluation is disabled.  A TAG or the COMMENt are visible
immediately.

In my opinion, excluding a subtree from export *and* evaluation
is not an esoteric use case and deserves better support.



 Just to confirm.  This is what you suggest, correct?

 --8---cut here---start-8---
 * test

 ** Not exported 
 :noexport:
:PROPERTIES:
:noeval: yes
:export: none
:END:
#+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
 --8---cut here---end---8---




 One may also want to COMMENT the subtree to inhibit it's export
 wholepiece (not just code blocks).

 This does not seem to work, as the test.png is also created here.

 Again, just to confirm.  This is your suggestion, correct?

 --8---cut here---start-8---
 * test

 ** COMMENT Not exported
#+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
 --8---cut here---end---8---


 Close, I meant the following alternative

 * test

 ** COMMENT Not exported
:PROPERTIES:
:noeval: yes
:END:
#+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



 So, my question to this thread is: What is the easiest way to disable a
 subtree during export completely so that also none of the code blocks is
 evaluated (regardless of its :session argument).


 My example immediately above.


 Or even more precisely: Couldn't the COMMENT keyword do exactly that?  I
 do not expect code from inside a COMMENT subtree to be considered during
 export.


 No.  This has been raised previously and there was a consensus that it
 is often desirable for code in a COMMENT section to be evaluated on
 export.  Personally I often stuff code blocks into COMMENT sections
 which I want run as part of my publishing process (e.g., to create
 resources used in the exported document).



Sorry for being unclear here.  I wanted to propose different
behaviour for TAGs (lets say :noexport:) and the COMMENT keyword.
I am perfectly fine with :noexport: only prohibiting export but
still allowing evaluation.

But I propose that COMMENT be more treated like a comment, so more
like a shorthand for commenting out that subtree using '# '.
That way, evaluation would be disabled.

I see two benefits:
1. It serves the use-case where one wants a subtree to be not
   exported and not evaluated.
2. It more resembles Orgs idea of comments.

And since the other use case (no export but still evaluation) is
still very well supported via :noexport: there would be not too
much loss.

(IIRC, the COMMENT keyword was close to removal from Orgs syntax
recently.  So, why not add some real additional functionality to
it?)

WDYT?

Regards,
Andreas

PS:  IIUC, Samuel proposed the same thing:

Re: [O] Babel should not work in the subtree marked as not exported

2014-03-14 Thread Sebastien Vauban
Samuel Wales wrote:
 No.  This has been raised previously and there was a consensus that it
 is often desirable for code in a COMMENT section to be evaluated on
 export.  Personally I often stuff code blocks into COMMENT sections
 which I want run as part of my publishing process (e.g., to create
 resources used in the exported document).

 i won't go against consensus, but to me the expectation is that it
 acts just like commented lines.

 for your use case, could you use a section marked noexport or
 org-export-with-tasks?  i would use the latter.

I was thinking as well that this had been discussed previously, and that
the decision had been:

- COMMENT is equivalent to noexport and noeval, i.e. no code blocks
  are run

- noexport just does that: no export, but code blocks can be run.

But I don't find any evidence of this.  I must have misunderstood.

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-14 Thread zwz
Samuel Wales samolog...@gmail.com writes:

 how about call lines?

 to me, they should not run if they are not supposed to be exported.

 is this a bug?

 * babel should not export a call line via todo kw
 *** NEXT to reproduce
 set org-export-with-tasks to nil
 *** NEXT this should not run
 #+call: hi(a=2)
 *** hi
 #+name: hi
 #+begin_src sh :var a=1
   echo hi $a
 #+end_src

Maybe this is a simple and clear way:
noexport means no export and no code running, either.
While if you want to get the code run, just call it somewhere
explicitly.
What do you think?




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-14 Thread Samuel Wales
please consider this a bug report.

On 3/13/14, Samuel Wales samolog...@gmail.com wrote:
 how about call lines?

 to me, they should not run if they are not supposed to be exported.

 is this a bug?

 * babel should not export a call line via todo kw
 *** NEXT to reproduce
 set org-export-with-tasks to nil
 *** NEXT this should not run
 #+call: hi(a=2)
 *** hi
 #+name: hi
 #+begin_src sh :var a=1
   echo hi $a
 #+end_src

 --
 The Kafka Pandemic: http://thekafkapandemic.blogspot.com

 The disease DOES progress.  MANY people have died from it.  And
 ANYBODY can get it.

 Denmark: free Karina Hansen NOW.



-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-14 Thread Eric Schulte
 Sorry for being unclear here.  I wanted to propose different
 behaviour for TAGs (lets say :noexport:) and the COMMENT keyword.
 I am perfectly fine with :noexport: only prohibiting export but
 still allowing evaluation.

 But I propose that COMMENT be more treated like a comment, so more
 like a shorthand for commenting out that subtree using '# '.
 That way, evaluation would be disabled.

 I see two benefits:
 1. It serves the use-case where one wants a subtree to be not
exported and not evaluated.
 2. It more resembles Orgs idea of comments.

 And since the other use case (no export but still evaluation) is
 still very well supported via :noexport: there would be not too
 much loss.

 (IIRC, the COMMENT keyword was close to removal from Orgs syntax
 recently.  So, why not add some real additional functionality to
 it?)

 WDYT?


This sounds like a good compromise to me.  As you say, this should
easily and visually support both use cases and is intuitive.  I've not
touched the export machinery myself, so I'll leave the implementation to
Nicolas but I definitely support this approach.

Best,


 Regards,
 Andreas

 PS:  IIUC, Samuel proposed the same thing:
 http://permalink.gmane.org/gmane.emacs.orgmode/83459



-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-13 Thread Eric Schulte

 So what is your suggestion for the OP to achieve what he is after?
 noexport and noeval at the same time.


I'm jumping in half way through here, but wouldn't setting the :noeval
property to yes and :export property to none on the subtree work?

One may also want to COMMENT the subtree to inhibit it's export
wholepiece (not just code blocks).

Best,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-13 Thread Andreas Leha
Hi Eric,

Eric Schulte schulte.e...@gmail.com writes:


 So what is your suggestion for the OP to achieve what he is after?
 noexport and noeval at the same time.


 I'm jumping in half way through here,

Thanks for jumping in.

 but wouldn't setting the :noeval
 property to yes and :export property to none on the subtree work?

Well, the property-setting works, but that is really cumbersome.  In a
typical org file, it takes 5 keystrokes to toggle the :noexport: tag
(C-c C-c n TAB RET).  But I do not want to count the keystrokes it take
to additionally set these properties.

Just to confirm.  This is what you suggest, correct?

--8---cut here---start-8---
* test

** Not exported:noexport:
   :PROPERTIES:
   :noeval: yes
   :export: none
   :END:
   #+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
--8---cut here---end---8---




 One may also want to COMMENT the subtree to inhibit it's export
 wholepiece (not just code blocks).

This does not seem to work, as the test.png is also created here.

Again, just to confirm.  This is your suggestion, correct?

--8---cut here---start-8---
* test

** COMMENT Not exported
   #+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
--8---cut here---end---8---


So, my question to this thread is: What is the easiest way to disable a
subtree during export completely so that also none of the code blocks is
evaluated (regardless of its :session argument).

Or even more precisely: Couldn't the COMMENT keyword do exactly that?  I
do not expect code from inside a COMMENT subtree to be considered during
export.


Regards,
Andreas






Re: [O] Babel should not work in the subtree marked as not exported

2014-03-13 Thread John Hendy
On Mar 13, 2014 5:49 PM, Andreas Leha andreas.l...@med.uni-goettingen.de
wrote:

 Hi Eric,

 Eric Schulte schulte.e...@gmail.com writes:

 
  So what is your suggestion for the OP to achieve what he is after?
  noexport and noeval at the same time.
 
 
  I'm jumping in half way through here,

 Thanks for jumping in.

  but wouldn't setting the :noeval
  property to yes and :export property to none on the subtree work?

 Well, the property-setting works, but that is really cumbersome.  In a
 typical org file, it takes 5 keystrokes to toggle the :noexport: tag
 (C-c C-c n TAB RET).  But I do not want to count the keystrokes it take
 to additionally set these properties.

 Just to confirm.  This is what you suggest, correct?

 --8---cut here---start-8---
 * test

 ** Not exported
 :noexport:
:PROPERTIES:
:noeval: yes
:export: none
:END:
#+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
 --8---cut here---end---8---



 
  One may also want to COMMENT the subtree to inhibit it's export
  wholepiece (not just code blocks).

 This does not seem to work, as the test.png is also created here.

 Again, just to confirm.  This is your suggestion, correct?

 --8---cut here---start-8---
 * test

 ** COMMENT Not exported
#+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
 --8---cut here---end---8---


 So, my question to this thread is: What is the easiest way to disable a
 subtree during export completely so that also none of the code blocks is
 evaluated (regardless of its :session argument).

 Or even more precisely: Couldn't the COMMENT keyword do exactly that?  I
 do not expect code from inside a COMMENT subtree to be considered during
 export.


Can we track down why I got different results for R vs. ditaa in my message
above? Couldn't we be chasing our tails if this is ditaa specific?

R is behaving like expected (no eval if tree marked noexport), ditaa is not.

John


 Regards,
 Andreas






Re: [O] Babel should not work in the subtree marked as not exported

2014-03-13 Thread Eric Schulte
Andreas Leha andreas.l...@med.uni-goettingen.de writes:

 Hi Eric,

 Eric Schulte schulte.e...@gmail.com writes:


 So what is your suggestion for the OP to achieve what he is after?
 noexport and noeval at the same time.


 I'm jumping in half way through here,

 Thanks for jumping in.

 but wouldn't setting the :noeval
 property to yes and :export property to none on the subtree work?

 Well, the property-setting works, but that is really cumbersome.  In a
 typical org file, it takes 5 keystrokes to toggle the :noexport: tag
 (C-c C-c n TAB RET).  But I do not want to count the keystrokes it take
 to additionally set these properties.


Not that bad C-c C-x p n RET yes, I get 8 to set noeval, if you've
done it already in that Org file.  You could also easily wrap this
behavior into a function and bind that to a key-chord.


 Just to confirm.  This is what you suggest, correct?

 --8---cut here---start-8---
 * test

 ** Not exported  
 :noexport:
:PROPERTIES:
:noeval: yes
:export: none
:END:
#+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
 --8---cut here---end---8---




 One may also want to COMMENT the subtree to inhibit it's export
 wholepiece (not just code blocks).

 This does not seem to work, as the test.png is also created here.

 Again, just to confirm.  This is your suggestion, correct?

 --8---cut here---start-8---
 * test

 ** COMMENT Not exported
#+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
 --8---cut here---end---8---


Close, I meant the following alternative

--8---cut here---start-8---
* test

** COMMENT Not exported
   :PROPERTIES:
   :noeval: yes
   :END:
   #+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
--8---cut here---end---8---



 So, my question to this thread is: What is the easiest way to disable a
 subtree during export completely so that also none of the code blocks is
 evaluated (regardless of its :session argument).


My example immediately above.


 Or even more precisely: Couldn't the COMMENT keyword do exactly that?  I
 do not expect code from inside a COMMENT subtree to be considered during
 export.


No.  This has been raised previously and there was a consensus that it
is often desirable for code in a COMMENT section to be evaluated on
export.  Personally I often stuff code blocks into COMMENT sections
which I want run as part of my publishing process (e.g., to create
resources used in the exported document).

Best,



 Regards,
 Andreas





-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-13 Thread Samuel Wales
how about call lines?

to me, they should not run if they are not supposed to be exported.

is this a bug?

* babel should not export a call line via todo kw
*** NEXT to reproduce
set org-export-with-tasks to nil
*** NEXT this should not run
#+call: hi(a=2)
*** hi
#+name: hi
#+begin_src sh :var a=1
  echo hi $a
#+end_src

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  And
ANYBODY can get it.

Denmark: free Karina Hansen NOW.



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-13 Thread Samuel Wales
 No.  This has been raised previously and there was a consensus that it
 is often desirable for code in a COMMENT section to be evaluated on
 export.  Personally I often stuff code blocks into COMMENT sections
 which I want run as part of my publishing process (e.g., to create
 resources used in the exported document).

i won't go against consensus, but to me the expectation is that it
acts just like commented lines.

for your use case, could you use a section marked noexport or
org-export-with-tasks?  i would use the latter.

if this has been raised before, please ignore.



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-12 Thread Sebastien Vauban
Rainer M Krug wrote:
 Ken Mankoff mank...@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.

 AFAIK, this depends if you use a session. When you are using a session,
 *all* code blocks are evaluated, if you do not set the header argument
 session, only the ones which are exported are evaluated - precisely the
 reason you give.

We should know if zwz uses a session or not. Because, IIUC, what he
reports is that all code blocks are evaluated, even the ones which are
not exported.

Best regards,
  Seb

-- 
Sebastien Vauban




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-12 Thread zwz
Sebastien Vauban sva-n...@mygooglest.com
writes:

 Rainer M Krug wrote:
 Ken Mankoff mank...@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.

 AFAIK, this depends if you use a session. When you are using a session,
 *all* code blocks are evaluated, if you do not set the header argument
 session, only the ones which are exported are evaluated - precisely the
 reason you give.

 We should know if zwz uses a session or not. Because, IIUC, what he
 reports is that all code blocks are evaluated, even the ones which are
 not exported.

 Best regards,
   Seb
I checked my org settings, and did not found anything about session.
And here is the options in the file:
#+OPTIONS:   H:2 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t

Is session turned on by default?




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-12 Thread zwz
Ken Mankoff mank...@gmail.com writes:

 Hi Andreas,

 On 2014-03-11 at 09:41, Andreas Leha wrote:
 Hi Ken,

 Ken Mankoff mank...@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.

I totally get you.
As I was not aware of the fact that it is session related, I used the
vague phrase.
Now I just want to know how to turn off session for some source block. 




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-12 Thread zwz
Rainer M Krug rai...@krugs.de writes:

 Ken Mankoff mank...@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.

 AFAIK, this depends if you use a session. When you are using a session,
 *all* code blocks are evaluated, if you do not set the header argument
 session, only the ones which are exported are evaluated - precisely the
 reason you give.

 Rainer


   -k.



In my example, I did not set the header argument session, and variable
org-babel-default-header-args has the value:
 (:results . replace)
 (:exports . code)
 (:cache . no)
 (:noweb . no)
 (:hlines . no)
 (:tangle . no))
However, the block still runs.




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-12 Thread John Hendy
 In my example, I did not set the header argument session, and variable
 org-babel-default-header-args has the value:
  (:results . replace)
  (:exports . code)
  (:cache . no)
  (:noweb . no)
  (:hlines . no)
  (:tangle . no))
 However, the block still runs.

I wanted to try and reproduce this, as I thought I had the *opposite*
issue previously. I was correct, granted it was on Org  8.0:
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00762.html

Code in :noexport: sections was not running, and I wanted to know how
I could get it to run (and I even had a :session argument). I took a
stab at your document with R and can't reproduce (behavior is the same
as in my post above). /However/, I get the same with you using ditaa,
even with no :session argument. Test file:

* Trying with R
Uses no =:session= argument; =R-yes.png= should be be created and
=R-no.png= should not.

** Don't run this   :noexport:

#+header: :file ./R-no.png :height 200
#+begin_src R :results output graphics

x - 1:10
y - x^2
plot(x,y)

#+end_src

** Run this

#+header: :file ./R-yes.png :height 200
#+begin_src R :results output graphics :exports results

x - 1:10
y - x^2
plot(x,y)

#+end_src
* Trying with ditaa

Uses no =:session= argument; =ditaa-yes.png= should be be created and
=ditaa-no.png= should not.

** Don't run this   :noexport:

#+BEGIN_SRC ditaa :file ./ditaa-no.png :cmdline -E
++---+---+---+---+---+---+---+  +---+---+---+---+---+---+---+---+
x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 |
++---+---+---+---+---+---+---+  +---+---+---+---+---+---+---+---+
#+END_SRC

** Run this

#+BEGIN_SRC ditaa :file ditaa-yes.png :cmdline -E
++---+---+---+---+---+---+---+  +---+---+---+---+---+---+---+---+
x   | 0 cRED | 0 | 0 | 0 | 0 | 0 | 0 | 0 |  | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 |
++---+---+---+---+---+---+---+  +---+---+---+---+---+---+---+---+
#+END_SRC

And here's my minimal config:

;; change accordingly
(add-to-list 'load-path ~/.elisp/org.git/lisp/)
(add-to-list 'load-path ~/.elisp/org.git/contrib/lisp)
(add-to-list 'load-path ~/.elisp/site-lisp/ess/lisp/)

(require 'ox-latex)

(org-babel-do-load-languages
 'org-babel-load-languages
 '((R . t)
(ditaa . t)))


So, I can reproduce, but the behavior is not the same with R. My
directory ends up with R-yes.png, and both ditaa-no.png *and*
ditaa-yes.png. Is there a way to track down the source of the
difference?


John



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-12 Thread Andreas Leha
Hi zwz,

zwz zhangwe...@gmail.com writes:

 Ken Mankoff mank...@gmail.com writes:

 Hi Andreas,

 On 2014-03-11 at 09:41, Andreas Leha wrote:
 Hi Ken,

 Ken Mankoff mank...@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.

 I totally get you.
 As I was not aware of the fact that it is session related, I used the
 vague phrase.
 Now I just want to know how to turn off session for some source block. 


That can be done with ':session none'.

- Andreas




[O] Babel should not work in the subtree marked as not exported

2014-03-11 Thread zwz
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.







Re: [O] Babel should not work in the subtree marked as not exported

2014-03-11 Thread Ken Mankoff

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.



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-11 Thread Andreas Leha
Hi Ken,

Ken Mankoff mank...@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.

Regards,
Andreas




Re: [O] Babel should not work in the subtree marked as not exported

2014-03-11 Thread Ken Mankoff
Hi Andreas,

On 2014-03-11 at 09:41, Andreas Leha wrote:
 Hi Ken,

 Ken Mankoff mank...@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.



Re: [O] Babel should not work in the subtree marked as not exported

2014-03-11 Thread Rainer M Krug
Ken Mankoff mank...@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.

AFAIK, this depends if you use a session. When you are using a session,
*all* code blocks are evaluated, if you do not set the header argument
session, only the ones which are exported are evaluated - precisely the
reason you give.

Rainer


   -k.



-- 
Rainer M. Krug

email: RMKrugatgmaildotcom


pgpTTgnYILt1h.pgp
Description: PGP signature