Skip to main content
Emacs

Return to Answer

added 434 characters in body
Source Link
NickD
NickD
  • 33.6k
  • 3
  • 30
  • 47

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.

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.

Source Link
NickD
NickD
  • 33.6k
  • 3
  • 30
  • 47

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.