From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephan Schmitt Subject: Re: [ANN] Org-babel integrated into Org-mode Date: Thu, 01 Jul 2010 01:08:10 +0200 Message-ID: <4C2BCE5A.8010502@cs.tu-berlin.de> References: <87wrtp78rg.fsf@gmail.com> <874oglofzs.fsf@fastmail.fm> <87sk4432t8.fsf@gmail.com> <87zkyc4fql.fsf@gmail.com> <878w5w30fi.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=47548 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OU6OJ-0000eN-93 for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 19:08:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OU6OH-0005Ko-Op for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 19:08:27 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:54793) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OU6OH-0005KS-JJ for emacs-orgmode@gnu.org; Wed, 30 Jun 2010 19:08:25 -0400 In-Reply-To: <878w5w30fi.fsf@gmail.com> 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: emacs-orgmode@gnu.org Hi, just to throw yet another idea into the discussion: Execute source blocks only after the user confirmed it ("Do you know what you are doing (Type y, n, !, or SPC)?"). ! and SPC will add the current org file to the variables org-babel-trusted-files and org-babel-trusted-permanently-files (also C-c C-v [ and C-u C-c C-v [ could do this). The latter will be saved for future sessions. And if you also had a command to clean up this variable, removing non-existing and/or old files from it... This way the control of code execution by org-babel would be on the file level instead of the global level. Greetings, Stephan Also sprach Eric Schulte: > 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 > > _______________________________________________ > 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