Re: execute src block during export (Re: Worg HTML export problem?)

[Max Nikulin]

On 12/11/2021 23:55, Thomas S. Dye wrote:
> Max Nikulin writes:
>
> > On 12/11/2021 00:24, Thomas S. Dye wrote:
> > > The original problem is likely due to the default header arguments in 
> > > ob-org.el, which are unusual.
> >
> > It is great that the problem is solved. I do not think however that 
> > something
> > inside ob-org.el may affect processing of a file before this package 
> > is loaded.
> >
> > > If I export both, then all is well.
> > > #+begin_src emacs-lisp :results value none :exports both
> > >   (org-babel-do-load-languages
> > >    'org-babel-load-languages
> > >    '((org . t)))
> > > #+end_src
> >
> > I feel that I have missed something. I do not see the purpose to 
> > include this
> > source block in user docs. I expect that for accidental usage it is more
> > convenient to type (require 'ob-org), while as a permanent settings it is
> > possible to do customize-variable org-babel-load-languages or to use
> > `add-to-list'.
>
> The source block is included to show the user how to modify their .emacs.

My ~/.emacs.d/init.el has (among other variables)

(custom-set-variables
 '(org-babel-load-languages (quote ((emacs-lisp . t) (C . t) (python . 
t))))
 ;; ...
)

I consider it better since it does not force immediate loading of Org if 
emacs is launched for a file of different type. Before sending the 
previous message I forgot to check Org manual. It recommends 
`org-babel-do-load-language' and it looks more prominent than 
customizing of the variable, however a more concise example is given a 
bit below

(require 'ob-closure)

Additional feature of `org-babel-do-load-language' is that the function 
can "unload" some languages, however it is not the case for 
initialization. That is why I disputed recommending more complicated 
example with `org-babel-do-load-language'. It is matter of taste however 
even if current example has no less obvious advantages.

> I was surprised that changing its :results header argument had an effect 
> on export.
>
> Do you have an explanation why the header argument makes this difference 
> on Worg?

Worg build procedure is more close to defaults. Earlier I wrote that the 
issue can be reproduced locally using "emacs -Q".

Actually it is reasonable that without explicit request, source blocks 
are not executed during export. `org-babel-default-header-args' has 
(:exports . "code"), so it is necessary to override default value to 
execute the source block loading ob-org.

I was confused that build log contains a message related to evaluating 
of some code ob-doc-sql.org without explicit overriding of :exports. 
Likely it is caused by noweb option.