#+BIND and org-mode asynchronous exporting document

Question

Let's say I have the following org-file:

#+TITLE: Presentation title
#+BIND: org-beamer-outline-frame-title "My own title"

#+LATEX_CLASS: beamer

* Section 1
** Slide 1

When I export this document in sync mode (org-beamer-export-to-pdf nil) it works ok.

But exporting in asynchronous mode throws Process `org-export-process` exited abnormally.

If I comment out the line with #+BIND command I can export in both modes.

I need to mention that according to these sources 1, 2, 3 I created my async_init.el with the following content:

(require 'package)
(setq package-enable-at-startup nil)
(package-initialize)

(require 'org) 
(require 'ox)
(require 'cl)
(require 'ox-beamer)
(setq org-export-allow-bind-keywords t)
(setq org-export-async-debug t)

and added the following to my init.el:

(setq org-export-in-background t)
(setq org-export-async-init-file (expand-file-name "~/.emacs.d/myarch/async_init.el"))

What am I missing to have async export working with #+BIND?

I found several threads with similar issue 4 5 6 but they give (me) no clue on what to do to solve the problem...

Answer 1

You are probably missing an initialization. Async is done by spawning a new Emacs process with a special initialization file (specified by org-export-async-init-file). If that file is incomplete in any way, the new Emacs process will not start and you will get the dreaded error you encounter.

org-export-async-start is the function that is called when you export with async mode enabled. When it starts the new process, it creates a proc buffer for it with:

    ...
    (proc-buffer (generate-new-buffer-name "*Org Export Process*"))
    ...

If the process fails, then it adds the buffer to a stack of such buffers created for async processes:

  (org-export-add-to-stack proc-buffer nil p)

and the buffer sticks around so you can examine it, even without setting org-export-async-debug (it is normally deleted on successful exit, but it is kept around even in that case if org-export-async-debug is set).

The stack is stored in org-export-stack-contents so you can switch to the first buffer in the stack with M-: (pop-to-buffer (car org-export-stack-contents)), but since the buffer has a special name (*Org Export Process* possibly followed by a <N> for some number N if you have more than one such failed process, you can just use C-x b to switch to the buffer. With org-export-async-debug set, the temporary file is also kept around: you can find it under /tmp/org-export-process<mumble> where <mumble> is some jumble of characters to disambiguate this temp file from others.

The buffer and the temp file should allow you to debug the problem. When I tried your example locally (without any org-export-async-init-file), the buffer showed me this:

Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such file or directory" "auctex-autoloads")
  load("auctex-autoloads")
  load-library("auctex-autoloads")
  eval-buffer(#<buffer  *load*-199044> nil "/home/nick/elisp/config/auctex-config.el" nil t)  ; Reading at buffer position 126
  load-with-code-conversion("/home/nick/elisp/config/auctex-config.el" "/home/nick/elisp/config/auctex-config.el" nil t)
  require(auctex-config)
  (if (experimental-enabled) (require 'auctex-config))
  eval-buffer(#<buffer  *load*> nil "/home/nick/.config/emacs/init.el" nil t)  ; Reading at buffer position 9932
  load-with-code-conversion("/home/nick/.config/emacs/init.el" "/home/nick/.config/emacs/init.el" nil t)
  load("/home/nick/.config/emacs/init.el" nil t)
  command-line-1(("-l" "/home/nick/.config/emacs/init.el" "-l" "/tmp/org-export-processA3Ppqe"))

so I would need to add some things to the load-path in the init file.

Hope this helps you debug the problem.

---

FWIW, when I try with your async-init.el and your init.el and your example, the async export succeeds, including the effect of #+BIND. I moved the setting of org-export-async-debug from the first to the second, although that does not matter to the success or failure: however it needs to be in init.el in order to allow you to debug problems - as mentioned in the comment, putting in async-init.el is ineffective.