Re: [ANN] Org-babel integrated into Org-mode

[Matthew Lundin <mdl@imapmail.org>]

Dan Davison <dandavison7@gmail.com> writes:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> You main proposal was to make Org Babel an optional module.
>>> This will not solve the problem fully, I think, because we also
>>> don't want that people who turn it on automatically commit
>>> to potentially dangerous operations.  There is a lot of good stuff
>>> in Babel which has nothing to do with code evaluation.
>>>
>>> Here is what I propose (several items are similar to what Eric proposes)
>>>
>>> 1. A new variable org-turn-on-babel.  We can discuss the default.
>>>    If it is nil, org-babel should not be loaded.
>>>    A default of t would be fine with me if we implement other
>>>    measures listed below.
>>>
>>
>> This sounds like a good idea to me, and it should address Matt's desire
>> for enabling minimal Org-mode installs.  I would like this to default to
>> t, so that new users can try out Org-babel without overmuch effort.
>
> I'm not clear yet what the point of this is. Unless it is the load time
> which is the issue, what else is gained by this variable? In principle
> I'm also all for minimalism and modularity, but what does it actually
> mean here?
>
> If the effect of this variable is to not load org-babel code at all,
> then this needs to be thought about carefully, as it is tantamount to a
> statement that all org-babel code is orthogonal to the rest of
> org-mode. I.e. core org-mode will not be able to make use of any
> org-babel code, because there will always be the risk that the user has
> set this variable to nil. Are we sure that we might not want some
> org-babel code (e.g. block export or tangling or something) to be used
> in core Org functionality?

Thanks Dan for this clarification. My primary concern had to do with the
risk org-babel introduces of executing problematic code. This concern
has been largely allayed by Eric's recent addition of a default
yes-or-no-p prompt before executing code in source blocks, along with
the option of disabling elisp evaluation. (I still fear accidentally
executing code during export, but that has to do with my lack of
familiarity with inline-src-blocks, which are evaluated by default on
export.)

You certainly have a far better understanding than I do of the potential
org-babel offers for org-mode's core functionality. The package is
indeed small compared to other features, so load time should not be much
of an issue. I very much appreciate the ways in which you and Eric have
made org-babel modular, loading a minimal framework by default and
leaving the selection of languages up to the user. My concern, I
suppose, has to do with the ever-growing complexity of org-mode.
Wherever possible, I would prefer to give users the freedom *not* to
load modules they don't need. That may be not be possible or desirable
in this case. So I am eager to learn more about ways in which org-babel
can enhance and simplify the core features of org-mode.

Please don't take any of these concerns as criticism of a package from
which I already benefit immensely. Far be it from me to look askance at
such a useful gift!

Best,
Matt