"Jorge P. de Morais Neto" <jorge+l...@disr.it> writes: > Hi. I am on Gentoo. I wrote the following Elisp function: > > --8<---------------cut here---------------start------------->8--- > (defun J-org-icalendar-agenda-no-babel (&optional async) > "Invoke `org-icalendar-combine-agenda-files' without babel, maybe ASYNC. > > Also, make broken Org links just get marked as such in the > output, instead of stopping the export with an error." > (interactive "P") > (let (org-export-use-babel > (org-export-with-broken-links 'mark)) > (org-icalendar-combine-agenda-files async))) > --8<---------------cut here---------------end--------------->8--- > > When I invoke (J-org-icalendar-agenda-no-babel t), the async export > errors out. I determined that the inferior Emacs process does not see > the let-binding (org-export-with-broken-links 'mark). Is this intended > behavior?
This is because async export code only tries hard to copy buffer-local variables (`org-export--generate-copy-script'). Global bindings are not transferred. I am not sure if transferring global bindings is something we should do. The existence of `org-export-async-init-file' implies that user may want to use different settings from the Emacs session. If we start transferring the full Org-related Emacs state to async process, users with custom `org-export-async-init-file' might be affected. On the other hand, your use-case clearly shows that the current behaviour can be confusing. So... Confirmed. One possible way to fix the confusion could be adding a new `org-export-async-preserve-global-state' variable. When non-nil, we will transfer global state in addition to the buffer-locals. But I would like to hear other opinions first, if there are any. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
