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

[Stephan Schmitt <drmabuse@cs.tu-berlin.de>]

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<dandavison7@gmail.com>  writes:
>
>> "Eric Schulte"<schulte.eric@gmail.com>  writes:
>>
>>> Hi Carsten, Matt, Scott,
>>>
>>> Carsten Dominik<carsten.dominik@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