Dan Davison <dandavis...@gmail.com> writes: > "Eric Schulte" <schulte.e...@gmail.com> writes: > >> Hi Carsten, Matt, Scott, >> >> Carsten Dominik <carsten.domi...@gmail.com> 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. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
