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
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode