From: "Eric Schulte" <schulte.eric@gmail.com>
To: Dan Davison <dandavison7@gmail.com>
Cc: Matt Lundin <mdl@imapmail.org>, Org Mode <emacs-orgmode@gnu.org>,
Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: [ANN] Org-babel integrated into Org-mode
Date: Wed, 30 Jun 2010 10:17:05 -0700 [thread overview]
Message-ID: <878w5w30fi.fsf@gmail.com> (raw)
In-Reply-To: <87zkyc4fql.fsf@gmail.com> (Dan Davison's message of "Wed, 30 Jun 2010 13:01:06 -0400")
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
next prev parent reply other threads:[~2010-06-30 17:17 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 21:09 [ANN] Org-babel integrated into Org-mode Eric Schulte
2010-06-23 23:23 ` Sebastian Rose
2010-06-23 23:41 ` Eric Schulte
2010-06-24 0:03 ` Bernt Hansen
2010-06-24 0:39 ` Eric Schulte
2010-06-24 5:12 ` Nathan Neff
2010-06-24 5:42 ` Eric Schulte
2010-06-24 7:31 ` Sébastien Vauban
2010-06-24 16:27 ` Eric Schulte
2010-06-25 8:28 ` Rainer M Krug
2010-06-25 15:37 ` Eric Schulte
2010-06-26 8:45 ` Štěpán Němec
2010-06-26 15:59 ` Eric Schulte
2010-06-26 16:30 ` Štěpán Němec
2010-06-26 17:27 ` Eric Schulte
2010-06-26 18:45 ` Stephan Schmitt
2010-06-26 19:42 ` Carsten Dominik
2010-06-26 19:51 ` Štěpán Němec
2010-06-28 7:55 ` Rainer M Krug
2010-06-28 11:53 ` Štěpán Němec
2010-06-28 12:16 ` Rainer M Krug
2010-06-28 12:54 ` Bernt Hansen
2010-06-28 13:18 ` Rainer M Krug
2010-06-28 13:25 ` Bernt Hansen
2010-06-28 13:36 ` Rainer M Krug
2010-06-28 16:03 ` Eric Schulte
2010-06-29 7:11 ` Rainer M Krug
2010-06-28 11:32 ` Christopher Witte
2010-06-28 16:59 ` Eric Schulte
2010-07-02 15:50 ` Christopher Witte
2010-06-29 18:23 ` Matt Lundin
2010-06-29 19:08 ` Nick Dokos
2010-06-29 21:01 ` Matt Lundin
2010-06-29 21:27 ` Matthew Lundin
2010-06-29 22:12 ` Nick Dokos
2010-06-29 22:03 ` Eric Schulte
2010-06-29 23:09 ` Eric Schulte
2010-06-29 23:11 ` Eric Schulte
2010-06-30 2:21 ` Nick Dokos
2010-06-30 5:37 ` Eric Schulte
2010-06-30 5:40 ` Eric Schulte
2010-06-30 12:13 ` Matthew Lundin
2010-06-30 9:27 ` Carsten Dominik
2010-06-30 9:59 ` Scot Becker
2010-06-30 12:53 ` Matthew Lundin
2010-06-30 13:24 ` Carsten Dominik
2010-06-30 16:25 ` Eric Schulte
2010-06-30 17:01 ` Dan Davison
2010-06-30 17:17 ` Eric Schulte [this message]
2010-06-30 23:08 ` Stephan Schmitt
2010-07-01 0:20 ` Matthew Lundin
2010-07-01 6:27 ` Carsten Dominik
2010-07-01 16:11 ` Nick Dokos
2010-07-01 20:24 ` Sébastien Vauban
2010-07-01 22:14 ` Nick Dokos
2010-06-30 19:41 ` Eric Schulte
2010-07-01 7:20 ` Carsten Dominik
2010-07-01 14:55 ` Eric Schulte
2010-07-01 20:39 ` Eric Schulte
2010-07-01 22:13 ` Christian Moe
2010-07-02 4:22 ` Carsten Dominik
2010-07-02 18:52 ` Eric Schulte
2010-07-02 8:38 ` Carsten Dominik
2010-06-30 19:01 ` Eric Schulte
2010-06-30 20:47 ` Matthew Lundin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878w5w30fi.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=dandavison7@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mdl@imapmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).