From: Max Nikulin <email@example.com>
Subject: Re: execute src block during export (Re: Worg HTML export problem?)
Date: Sat, 13 Nov 2021 19:17:23 +0700 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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
>> 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 . t)))
>> 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
> The source block is included to show the user how to modify their .emacs.
My ~/.emacs.d/init.el has (among other variables)
'(org-babel-load-languages (quote ((emacs-lisp . t) (C . t) (python .
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
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.
prev parent reply other threads:[~2021-11-13 12:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-07 22:46 Worg HTML export problem? Thomas S. Dye
2021-11-10 16:50 ` Max Nikulin
2021-11-10 21:24 ` Thomas S. Dye
2021-11-11 13:00 ` execute src block during export (Re: Worg HTML export problem?) Max Nikulin
2021-11-11 17:24 ` Thomas S. Dye
2021-11-12 14:26 ` Max Nikulin
2021-11-12 16:55 ` Thomas S. Dye
2021-11-13 12:17 ` Max Nikulin [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).