From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: [ANN] Org-babel integrated into Org-mode Date: Wed, 30 Jun 2010 10:17:05 -0700 Message-ID: <878w5w30fi.fsf@gmail.com> References: <87wrtp78rg.fsf@gmail.com> <874oglofzs.fsf@fastmail.fm> <87sk4432t8.fsf@gmail.com> <87zkyc4fql.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=33455 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OU0uq-0006hY-Qs for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 13:17:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OU0up-0008KT-At for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 13:17:40 -0400 Received: from mail-px0-f169.google.com ([209.85.212.169]:46865) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OU0up-0008KC-1f for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 13:17:39 -0400 Received: by pxi17 with SMTP id 17so1091170pxi.0 for ; Wed, 30 Jun 2010 10:17:36 -0700 (PDT) In-Reply-To: <87zkyc4fql.fsf@gmail.com> (Dan Davison's message of "Wed, 30 Jun 2010 13:01:06 -0400") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Dan Davison Cc: Matt Lundin , Org Mode , Carsten Dominik Dan Davison writes: > "Eric Schulte" writes: > >> Hi Carsten, Matt, Scott, >> >> Carsten Dominik 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