Christian Moe <[email protected]> writes:
3. Most blocks will not be evaluated in any case, since the
default
setting is =:eval no-export=. The exceptions are the ob-doc-*
files
for ditaa, dot, elisp, and org, which have some explicit
=:eval yes=
flags. There's an issue with ob-doc-dot.org that we need to
look into
("Babel evaluation exited with code 127"), but otherwise
these files
do not raise any warnings when exported.
The ditaa and dot documents didn't require =:eval yes=. I've
edited them so they look fine without evaluation.
The elisp and org documents are structured differently, mostly to
show the html export of code. I don't know if this feature is
worth keeping; the exported code is fontified, so it looks more
colorful than an example code block, but the content is otherwise
redundant.
Also, these two languages are self-referential in ways that I find
perplexing---I haven't convinced myself that =:eval yes= can be
removed :(
WDYT?
To the extent there is a policy in place, it is that code
evaluation on
the server upon expert is not allowed, but local exceptions can
be made
for a few supported languages
(https://orgmode.org/worg/worg-setup.html). As such, the
continuous
integration of src block results is limited.
It's cool, and possibly useful, to have the option of
dynamically
updated graphics done in, say ditaa or R with with data from sh
and
elisp. I think we should keep existing cases as long as the
maintenance
burden is tolerable and any build problems can be resolved. As
Ihor
says, it's an additional test layer. We could even consider
enabling a
few additional languages if there's a clear use case for them.
(Latex
would be nice, but probably way too heavy.)
The ability to generate graphics on the fly in the build also
potentially means the repository itself could be kept smaller,
at the
cost of more processing. But again, I think we generally want
the
illustrations tracked by Git, and that a contributor's default
approach
should be to initially commit and upload them.
Thomas S. Dye writes:
Christian, I'm happy to edit the ob-doc-*.org files to
standardize.
If the CI approach is better, then I'm happy with that, too.
Thanks for the offer, but I don't think we need to standardize.
We can
solve specific problems as we find them.
WDYT?
Agreed.
I'm thinking about standardization mostly in case the ob-doc-*
documentation is added to the Org manual, but a uniform look and
feel on Worg would be nice, too. A solution that looks good on
Worg and ports easily to the Org manual would be best.
All the best,
Tom
--
Thomas S. Dye
https://tsdye.online/tsdye
