EDIT 1 : a more simple use case

For this org file content:

* Headline 1 
  - Something to export

* Headline 2      :noexport:
  #+begin_src python :results none :exports none 
  def foo():

A simple html export (C-c C-e h o) leads to a processing of the python code block event if it is located in a noexport section: org-babel-exp process python at position 116...

Since I have hundreds of code blocks under non exported headlines, this leads to non useful long processing times. Is it possible to avoid this ?

Initial Question:

I have the following problem: I use a selective export with tags thanks to the following code:

#+name: myexporter 
#+BEGIN_SRC emacs-lisp
(defun myexporter (tags filename)
      ((org-export-select-tags tags) (async nil) (subtreep nil) (visible-only nil) (body-only nil) (ext-plist '())) 
      (org-export-to-file 'html filename async subtreep visible-only body-only)))

#+name: selectiveexport
#+BEGIN_SRC emacs-lisp :noweb yes 
(myexporter '("bar") "bar.html")

This code enables to select all sections with tag :bar: and export them to an html file called bar.html.

My problem is that when I call the selective export all code block are systematically processed (and I have a lot in my file which makes the selective export quite slow).

For example, with the following org file

* Test :bar:
  - Bla, bla

* Foo       
  #+name: foo
  #+begin_src python :results none :exports none
  def foo():

the selective export leads to the following messages :

executing Emacs-Lisp code block (selectiveexport)...
org-babel-exp process emacs-lisp at position 21...
org-babel-exp process emacs-lisp at position 337...
org-babel-exp process python at position 796...
Saving file [...]/bar.html...

My problem is the org-babel-exp process python at position 796 that I would prefer not to be executed. I precise that it is executed even if a :noexport: tag is assigned to section Foo.

Is it possible to avoid this processing step ?

1 Answer 1


The reason that org-babel evaluates code blocks in :noexport: sections is that it does not know what depends on what and makes the worst-case assumption that any code block results you choose to export depend on every code block in the file. It's not an unreasonable assumption: presumably you chose to put all these code blocks in the same file exactly because they all work together to produce the results that you want to see.

But since the user might know better, there is an option to prevent evaluation of a code block on export, by using the eval header argument:

#+begin_src python :eval never-export :results none :exports none

See the Exporting Code Blocks section in the manual, particularly the last three paragraphs:

To stop Org from evaluating code blocks to speed exports, use the header argument ‘:eval never-export’ (see Evaluating Code Blocks). To stop Org from evaluating code blocks for greater security, set the org-export-use-babel variable to nil, but understand that header arguments will have no effect.

Turning off evaluation comes in handy when batch processing. For example, markup languages for wikis, which have a high risk of untrusted code. Stopping code block evaluation also stops evaluation of all header arguments of the code block. This may not be desirable in some circumstances. So during export, to allow evaluation of just the header arguments but not any code evaluation in the source block, set ‘:eval never-export’ (see Evaluating Code Blocks).

Org never evaluates code blocks in commented sub-trees when exporting (see Comment Lines). On the other hand, Org does evaluate code blocks in sub-trees excluded from export (see Export Settings).

EDIT: the org-babel-exp process... messages you are getting are not going to go away by using :eval never-export. Babel always has to "process" the code block to at least find out what the headers are telling it to do. But the code block is not evaluated. Try this to convince yourself that that is the case:

* Headline 2 :noexport:
  #+begin_src python :results output :exports results :eval never-export
  import time
  def foo():

Try exporting with and without the :eval never-export header. Without it, the export will take 10 seconds; with it, the export is instant.

  • Thanks for your detailed answer, however, even with a :eval never-export header argument, the code block is still processed, I do not understand why.
    – Lgen
    May 7, 2019 at 7:21
  • I use org-mode 9.2.3
    – Lgen
    May 7, 2019 at 8:04
  • The code block has to be processed (at least its headers have to be processed) to find out what needs to be done: that's what that org-babel-exp process... message tells you. But the code block is not evaluated.
    – NickD
    May 7, 2019 at 13:54
  • 1
    @Lgen - Just before a SRC block is executed or exported, most of the header properties are evaluated, e.g. :var, :tangle, :noweb, :eval. These header properties need to be evaluated before execution or export to fetch up to date property values dynamically. As @NickD explained that's why you still see org-babel-process message even though the SRC block code isn't evaluated. Hope that helps.
    – Melioratus
    May 7, 2019 at 14:55
  • 1
    @melioratus Thanks for these additional elements; I understand from your comment (and the one of NickD) that the headers processing is always achieved. It seems that the :noweb references processing is a large part of the time required but I need to investigate further to be sure.
    – Lgen
    May 13, 2019 at 9:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.