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

[Eric Schulte]

Dan Davison <address@hidden> writes:

> "Eric Schulte" <address@hidden> writes:
>
>> Hi Carsten, Matt, Scott,
>>
>> Carsten Dominik <address@hidden> writes:
>>
[...]
>>> 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?
>
> As an example of an area of overlap of core org-mode and babel, I'd been
> considering extending the [[shell:]] and [[elisp:]] links that are
> present in core Org-mode to support other languages. If that happens it
> might make sense to let babel code handle the shell and elisp
> evaluation, rather than having that functionality duplicated in the code
> base.
>
> Essentially I had been envisioning the incorporation of org-babel into
> org-mode as the beginning of a phase in which the code bases can
> interact and evolve together, rather than as a promise of eternal
> orthogonality.
>

Thanks for bringing this up Dan, I think you're right that this is a
very important point, which I had missed in my rush to defend the
evaluation 'C-c C-c' keybinding.  For simplicity, for maintainability,
for code cleanliness, and to remove significant duplication of code and
functionality, I agree that it is important for Babel to be part of
Org-mode rather than a detachable module.

As an alternative to adding a configuration option to strip all of Babel
out of Org-mode, perhaps we should add an option for users who are sure
that they will never want to evaluate code blocks to *not* load
emacs-lisp support.  With no language support loaded, then all of the
Babel functions are part of Org-mode, but there is no way that any
source code can actually be executed.

Best -- Eric