[ANN] Org-babel integrated into Org-mode

[ANN] Org-babel integrated into Org-mode

[Eric Schulte]

Hi,

I've just merged the babel branch into the main branch of Org-mode.
This merge culminates much integration work by Dan Davison and Tom Dye,
as well as myself.

Babel is now part of Org-mode.

The biggest changes are:

1) Babel now has documentation!  It is part of Org-mode's documentation
   
   see Chapter 14 _Working With Source Code_

   also, the Babel keybindings are now listed in the refcard, and can be
   viewed from any Org-mode buffer by pressing C-c C-v h

2) Babel will now be loaded by default along with the rest of Org-mode.
   This means that *everyone* currently using babel will need to change
   their Emacs config and remove the (require 'org-babel-int) and/or
   (require 'org-babel) lines.
   
   Support for evaluating emacs-lisp code blocks is loaded by default.
   All other languages will need to be required explicitly.  To conform
   to Emacs filename specifications all language require lines have been
   shortened from e.g.
   
   (require 'org-babel-sh)
   
   to
   
   (require 'ob-sh)

Thanks -- Eric

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

[Sebastian Rose]

"Eric Schulte" <schulte.eric@gmail.com> writes:
> Hi,
>
> I've just merged the babel branch into the main branch of Org-mode.
> This merge culminates much integration work by Dan Davison and Tom Dye,
> as well as myself.
>
> Babel is now part of Org-mode.


Hi Eric,



it seems ob-oz.el is not renamed as intended?


This happend when I pulled:


  sh$ cd emacs/lisp/ext/org-mode
  sh$ git pull
  ...
  rename contrib/babel/{lisp/langs/org-babel-oz.el => langs/ob-oz.el} (97%)
  delete mode 100644 contrib/lisp/org-babel-init.el
  rename contrib/babel/lisp/langs/org-babel-C.el => lisp/babel/langs/ob-C.el (92%)
  rename contrib/babel/lisp/langs/org-babel-R.el => lisp/babel/langs/ob-R.el (94%)
  ...

  sh$ ls contrib/babel/langs/
  ob-oz.el


Is this intended?





Best wishes

  Sebastian

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

[Eric Schulte]

Hi Sebastian,

Sebastian Rose <sebastian_rose@gmx.de> writes:

[...]
>
> it seems ob-oz.el is not renamed as intended?
>

Ah, I should have mentioned.

ob-oz.el is the only language-specific file for which we were not able
to secure FSF copyright assignment.  For this reason it still lives in
the contrib directory, under

  org/contrib/babel/langs/

For consistency it should be renamed to ob-oz.el (a change which I just
pushed up).

the following should now work
--8<---------------cut here---------------start------------->8---
(add-to-list 'load-path "~/your/path/to/org/contrib/babel/langs/")
(require 'ob-oz)
--8<---------------cut here---------------end--------------->8---

Thanks for catching this -- Eric

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

[Bernt Hansen]

"Eric Schulte" <schulte.eric@gmail.com> writes:

>    Support for evaluating emacs-lisp code blocks is loaded by default.
>    All other languages will need to be required explicitly.  To conform
>    to Emacs filename specifications all language require lines have been
>    shortened from e.g.
>    
>    (require 'org-babel-sh)
>    
>    to
>    
>    (require 'ob-sh)

Hi Eric,

The documentation still has (require 'org-babel-identifier) and should
probably be updated.

Regards,
Bernt

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

[Eric Schulte]

Bernt Hansen <bernt@norang.ca> writes:

>
> The documentation still has (require 'org-babel-identifier) and should
> probably be updated.
>

updated, Thanks -- Eric

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

[Nathan Neff]

I checked out the latest org mode, and I'm getting "Symbol's function
definition is void: second"

I ran git-bisect, and the error was introduced with the merge of
org-babel into the main
branch.

The code that's causing the error is here:

#+tblname:shortcut-definition-list
| Something       | <f6> a    | A33F7A0C-F974-4C7F-A4FD-1AAA6CF9C60E |

#+srcname: map-nav(shortcut-definition-list=shortcut-definition-list)
#+begin_src emacs-lisp
(defun map-navigation-shortcuts(shortcut-def)
(global-set-key (read-kbd-macro (second shortcut-def))
                 (lexical-let ((shortcut-def shortcut-def))
                   (lambda ()
                     (interactive)
                     (org-id-goto (third shortcut-def))))))
(mapcar #'map-navigation-shortcuts shortcut-definition-list)


------------------------
This is the cool "use a table to map keyboard shortcuts" code that was
given to me in this conversation:

http://www.mail-archive.com/emacs-orgmode@gnu.org/msg24971.html

I've verified that the above code works with org-babel outside of the
main branch, at this commit:
commit a3cc050a9675127f4f9fb85ba30cb5c0b4417cf8
Author: Eric Schulte <schulte.eric@gmail.com>
Date:   Fri Apr 30 13:03:38 2010 -0600

Any ideas?

Should I try to find the exact commit where it starts failing?

Thanks,
--Nate

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

[Eric Schulte]

Hi Nathan,

Nathan Neff <nathan.neff@gmail.com> writes:

> I checked out the latest org mode, and I'm getting "Symbol's function
> definition is void: second"
>
> I ran git-bisect, and the error was introduced with the merge of
> org-babel into the main
> branch.
>

Part of merging into Org-mode (and meeting the Emacs code standards)
meant that Org-babel had to stop requiring the 'cl library which
provides the `second' function.  There's a good editorial on this issue
available online [1] (published from an org-mode file).

I would recommend that you either
1) add (require 'cl) to your personal configuration
2) add (require 'cl) to the top of the emacs-lisp code block
3) or make the following replacements in the code block
   - (second shortcut-def) -> (nth 1 shortcut-def)
   - (third shortcut-def) -> (nth 2 shortcut-def)

Hope this helps, let me know if problems persist.

Best -- Eric

Footnotes: 
[1]  http://dto.github.com/notebook/require-cl.html#sec-8

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

[Sébastien Vauban]

Hi Eric,

> I've just merged the babel branch into the main branch of Org-mode.
>
> [...]
>
> 2) Babel will now be loaded by default along with the rest of Org-mode. This
>    means that *everyone* currently using babel will need to change their
>    Emacs config and remove the (require 'org-babel-int) and/or (require
>    'org-babel) lines.
>
>    Support for evaluating emacs-lisp code blocks is loaded by default. All
>    other languages will need to be required explicitly. To conform to Emacs
>    filename specifications all language require lines have been shortened
>    from e.g.
>
>    (require 'org-babel-sh)
>
>    to
>
>    (require 'ob-sh)

For my own understanding, what's the status of `Org-babel-screen', for which
I've never been able to understand completely all the differences with `sh' in
`Org-babel'?

Second, a problem with the following code:

--8<---------------cut here---------------start------------->8---
      ;; Org-babel needs to be told to recognize awk source code blocks and
      ;; how they should be tangled, which can be accomplished with the
      ;; following:
      (org-babel-add-interpreter "awk")
      (add-to-list 'org-babel-tangle-langs '("awk" "awk"))

      (org-babel-add-interpreter "fortran")
      (add-to-list 'org-babel-tangle-langs '("fortran" "f"))

      ;; ;; org-babel panics when trying to evaluate ruby code blocks because
      ;; ;; you don't have the required ruby executables available on your
      ;; ;; system. Probably the best way to deal with this is to remove ruby
      ;; ;; from the list of languages supported by babel:
      ;; (setq org-babel-interpreters (delete "ruby" org-babel-interpreters))

      ;; make pre-built helper functions (`lob') available
      ;; (org-babel-load-library-of-babel)

      ;; mapping between languages (listings in LaTeX) and their major mode
      ;; (in Emacs)
      (setq org-src-lang-modes
            '(("ocaml" . tuareg)
              ("elisp" . emacs-lisp)
              ;; ("Delphi" . perl)
              ("ditaa" . artist)
              ("asymptote" . asy)
              ("dot" . fundamental)))
      ;; )
--8<---------------cut here---------------end--------------->8---

Neither org-babel-add-interpreter, neither its shorter version do exist now?

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

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

[Eric Schulte]

Hi Sébastien,

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:

[...]
>
> For my own understanding, what's the status of `Org-babel-screen', for which
> I've never been able to understand completely all the differences with `sh' in
> `Org-babel'?
>

I believe screen has more of a focus on sustained interaction with an
interactive terminal, although to be honest I haven't really used it and
can't say for sure.  Benjamin Andresen, the author, may have a more
satisfying answer for you.

>
> Second, a problem with the following code:
>
>       ;; Org-babel needs to be told to recognize awk source code blocks and
>       ;; how they should be tangled, which can be accomplished with the
>       ;; following:
>       (org-babel-add-interpreter "awk")
>       (add-to-list 'org-babel-tangle-langs '("awk" "awk"))
>
>       (org-babel-add-interpreter "fortran")
>       (add-to-list 'org-babel-tangle-langs '("fortran" "f"))
>
>       ;; ;; org-babel panics when trying to evaluate ruby code blocks because
>       ;; ;; you don't have the required ruby executables available on your
>       ;; ;; system. Probably the best way to deal with this is to remove ruby
>       ;; ;; from the list of languages supported by babel:
>       ;; (setq org-babel-interpreters (delete "ruby" org-babel-interpreters))
>
>       ;; make pre-built helper functions (`lob') available
>       ;; (org-babel-load-library-of-babel)
>
>       ;; mapping between languages (listings in LaTeX) and their major mode
>       ;; (in Emacs)
>       (setq org-src-lang-modes
>             '(("ocaml" . tuareg)
>               ("elisp" . emacs-lisp)
>               ;; ("Delphi" . perl)
>               ("ditaa" . artist)
>               ("asymptote" . asy)
>               ("dot" . fundamental)))
>       ;; )
>
> Neither org-babel-add-interpreter, neither its shorter version do exist now?
>

Yes, thanks for bringing this up! I realized last night that I forgot to
mention this in the announcement.

We have simplified the handling of languages in Org-babel, in that the
org-babel-interpreters and org-babel-tangle-langs variables have both
been removed.

Rather than keeping explicit lists of supported languages, Babel will
now try to work with every language, and will only give up if it can't
find a needed function (e.g. if there is no org-babel-execute:foo
function defined then babel will give up on evaluating a foo code
block).  The only remaining language list is
`org-babel-tangle-lang-exts' which can optionally be used to associate
file extensions with language names, but is *not* required for
evaluation or tangling.

Given this, your configuration from above could be rewritten as

--8<---------------cut here---------------start------------->8---
      ;; Org-babel now needs less hand-holding :) however it could be
      ;; useful to know extensions for some languages
      (add-to-list 'org-babel-tangle-lang-exts '("fortran" . "f"))

      ;; mapping between languages (listings in LaTeX) and their major mode
      ;; (in Emacs)
      (setq org-src-lang-modes
            '(("ocaml" . tuareg)
              ("elisp" . emacs-lisp)
              ;; ("Delphi" . perl)
              ("ditaa" . artist)
              ("asymptote" . asy)
              ("dot" . fundamental)))
      ;; )
--8<---------------cut here---------------end--------------->8---

Cheers -- Eric

>
> Best regards,
>   Seb

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

[Rainer M Krug]

[-- Attachment #1.1: Type: text/plain, Size: 5993 bytes --]

Hi

First of all thanks for integrating Org-babel into Org-mode.

But for the less fluent elisp and org-mode users, I am slightly confused in
the changes necessary on my side.

I have the following in my emacs.org file:


#+begin_src emacs-lisp
  (require 'org-babel-R)         ;; requires R and ess-mode
  ;; (require 'org-babel-ruby)      ;; requires ruby, irb, ruby-mode, and
inf-ruby
  (require 'org-babel-python)    ;; requires python, and python-mode
  ;; (require 'org-babel-clojure)   ;; requires clojure, clojure-mode,
swank-clojure and slime
#+end_src
*** Start babel
#+begin_src emacs-lisp
  (org-babel-load-library-of-babel)
#+end_src
*** Customization of sh
  set shebang for sh script to "#!/bin/bash" and exclude additional comments
(t)
#+begin_src emacs-lisp
  (setq org-babel-tangle-langs
  (cons
  '("sh" "sh" "#!/bin/bash" t)
  (remove-if (lambda (el) (string= (car el) "sh")) org-babel-tangle-langs)))
#+end_src
*** Customization of R
  set shebang for R script to "" and exclude additional comments (t)
#+begin_src emacs-lisp
  (setq org-babel-tangle-langs
  (cons
  '("R" "R")
  (remove-if (lambda (el) (string= (car el) "R")) org-babel-tangle-langs)))
#+end_src

which custimizes the shebang creation and the comments in the tangled file.
Do I have to change any settings, and if yes, how? The previous conversation
seems to say "yes, it needs to be changed", but I don't understand what and
how.


Thanks,

Rainer.
On Thu, Jun 24, 2010 at 6:27 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> Hi Sébastien,
>
> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
>
> [...]
> >
> > For my own understanding, what's the status of `Org-babel-screen', for
> which
> > I've never been able to understand completely all the differences with
> `sh' in
> > `Org-babel'?
> >
>
> I believe screen has more of a focus on sustained interaction with an
> interactive terminal, although to be honest I haven't really used it and
> can't say for sure.  Benjamin Andresen, the author, may have a more
> satisfying answer for you.
>
> >
> > Second, a problem with the following code:
> >
> >       ;; Org-babel needs to be told to recognize awk source code blocks
> and
> >       ;; how they should be tangled, which can be accomplished with the
> >       ;; following:
> >       (org-babel-add-interpreter "awk")
> >       (add-to-list 'org-babel-tangle-langs '("awk" "awk"))
> >
> >       (org-babel-add-interpreter "fortran")
> >       (add-to-list 'org-babel-tangle-langs '("fortran" "f"))
> >
> >       ;; ;; org-babel panics when trying to evaluate ruby code blocks
> because
> >       ;; ;; you don't have the required ruby executables available on
> your
> >       ;; ;; system. Probably the best way to deal with this is to remove
> ruby
> >       ;; ;; from the list of languages supported by babel:
> >       ;; (setq org-babel-interpreters (delete "ruby"
> org-babel-interpreters))
> >
> >       ;; make pre-built helper functions (`lob') available
> >       ;; (org-babel-load-library-of-babel)
> >
> >       ;; mapping between languages (listings in LaTeX) and their major
> mode
> >       ;; (in Emacs)
> >       (setq org-src-lang-modes
> >             '(("ocaml" . tuareg)
> >               ("elisp" . emacs-lisp)
> >               ;; ("Delphi" . perl)
> >               ("ditaa" . artist)
> >               ("asymptote" . asy)
> >               ("dot" . fundamental)))
> >       ;; )
> >
> > Neither org-babel-add-interpreter, neither its shorter version do exist
> now?
> >
>
> Yes, thanks for bringing this up! I realized last night that I forgot to
> mention this in the announcement.
>
> We have simplified the handling of languages in Org-babel, in that the
> org-babel-interpreters and org-babel-tangle-langs variables have both
> been removed.
>
> Rather than keeping explicit lists of supported languages, Babel will
> now try to work with every language, and will only give up if it can't
> find a needed function (e.g. if there is no org-babel-execute:foo
> function defined then babel will give up on evaluating a foo code
> block).  The only remaining language list is
> `org-babel-tangle-lang-exts' which can optionally be used to associate
> file extensions with language names, but is *not* required for
> evaluation or tangling.
>
> Given this, your configuration from above could be rewritten as
>
> --8<---------------cut here---------------start------------->8---
>       ;; Org-babel now needs less hand-holding :) however it could be
>      ;; useful to know extensions for some languages
>      (add-to-list 'org-babel-tangle-lang-exts '("fortran" . "f"))
>
>      ;; mapping between languages (listings in LaTeX) and their major mode
>      ;; (in Emacs)
>      (setq org-src-lang-modes
>            '(("ocaml" . tuareg)
>              ("elisp" . emacs-lisp)
>              ;; ("Delphi" . perl)
>              ("ditaa" . artist)
>              ("asymptote" . asy)
>              ("dot" . fundamental)))
>      ;; )
> --8<---------------cut here---------------end--------------->8---
>
> Cheers -- Eric
>
> >
> > Best regards,
> >   Seb
>
> _______________________________________________
> 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
>



-- 
NEW GERMAN FAX NUMBER!!!

Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Cell:           +27 - (0)83 9479 042
Fax:            +27 - (0)86 516 2782
Fax:            +49 - (0)321 2125 2244
email:          Rainer@krugs.de

Skype:          RMkrug
Google:         R.M.Krug@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 9964 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Eric Schulte]

Hi Rainer,

First I'll give some expanded instructions in the hopes of helping out
anyone else affected by my lack of good instructions in the announcement
email.  Then I'll provide a re-write of your config below as an example.

Babel took the integration into Org-mode as an opportunity to do some
much needed house cleaning.  Most importantly we have cleared out
unnecessary configuration variables -- which is great unless you already
have these variables set.

We have eliminated the two main internal lists of languages, namely
- org-babel-interpreters and
- org-babel-tangle-langs
so any config lines which mention those variables, can/should be
stripped out in their entirety.  This includes any calls to the
`org-babl-add-interpreter' function, whose sole purpose was to add
languages to the org-babel-interpreters variable.

alright, so with those calls stripped out, we may still in some cases
want to associate a file name extension with certain languages, for
example we want all of our emacs-lisp files to end in a ".el", we can do
this will the `org-babel-tangle-lang-exts' variable.  In general you
shouldn't need to touch this as it already has defaults for most common
languages, and if a language is not present in org-babel-tangle-langs,
then babel will just use the language name, so for example a file of c
code will have a ".c" extension by default, sh code will have a ".sh"
extension ect...

You also mentioned shebang lines.  This configuration now lives in
header arguments.  So the shebang for a single file can be set at the
code block level, e.g.

#+begin_src clojure :shebang #!/usr/bin/env clj
  (println "with a shebang line, I can be run as a script!")
#+end_src

note that whenever a file is tangled which includes a shebang line,
org-babel will make the file executable, so there is good reason to only
add shebangs at the source-code level.  However if you're sure that you
want all of your code in some language (say shell scripts) to tangle out
with shebang lines, then you can customize the default header arguments
for that language, e.g.

;; ensure this variable is defined defined
(unless (boundp 'org-babel-default-header-args:sh)
  (setq org-babel-default-header-args:sh '()))

;; add a default shebang header argument
(add-to-list 'org-babel-default-header-args:sh
             '(:shebang . "#!/bin/bash"))

The final change, is that to conform to Emacs guidelines, the prefix
org-babel-* in all require lines, has been changed to ob-*, also, since
Babel now loads by default with Org-mode you can remove any
  (require 'org-babel)
or 
  (require 'org-babel-init)
that may by lying around your configuration.

Whew! that was alot of writing for a /simplification/ of configuration.
Hopefully the example of your configuration below will be a more
succinct demonstration of the needed transformations.

Rainer M Krug <r.m.krug@gmail.com> writes:

> Hi
>
> First of all thanks for integrating Org-babel into Org-mode.
>
> But for the less fluent elisp and org-mode users, I am slightly confused in
> the changes necessary on my side.
>
> I have the following in my emacs.org file:
>
>
> #+begin_src emacs-lisp
>   (require 'org-babel-R)         ;; requires R and ess-mode
>   ;; (require 'org-babel-ruby)      ;; requires ruby, irb, ruby-mode, and
> inf-ruby
>   (require 'org-babel-python)    ;; requires python, and python-mode
>   ;; (require 'org-babel-clojure)   ;; requires clojure, clojure-mode,
> swank-clojure and slime
> #+end_src

the above becomes

#+begin_src emacs-lisp
  (require 'ob-R)
  ;; (require 'ob-ruby)
  (require 'ob-python)
  ;; (require 'ob-clojure)
#+end_src

> 
> *** Start babel
> #+begin_src emacs-lisp
>   (org-babel-load-library-of-babel)
> #+end_src

the above becomes

#+begin_src emacs-lisp
  (org-babel-lob-ingest "~/path/to/org/contrib/babel/library-of-babel.org")
#+end_src

> 
> *** Customization of sh
>   set shebang for sh script to "#!/bin/bash" and exclude additional comments
> (t)
> #+begin_src emacs-lisp
>   (setq org-babel-tangle-langs
>   (cons
>   '("sh" "sh" "#!/bin/bash" t)
>   (remove-if (lambda (el) (string= (car el) "sh")) org-babel-tangle-langs)))
> #+end_src

#+begin_src emacs-lisp
  ;; ensure this variable is defined defined
  (unless (boundp 'org-babel-default-header-args:sh)
    (setq org-babel-default-header-args:sh '()))

  ;; add a default shebang header argument
  (add-to-list 'org-babel-default-header-args:sh
               '(:shebang . "#!/bin/bash"))
#+end_src

> 
> *** Customization of R
>   set shebang for R script to "" and exclude additional comments (t)
> #+begin_src emacs-lisp
>   (setq org-babel-tangle-langs
>   (cons
>   '("R" "R")
>   (remove-if (lambda (el) (string= (car el) "R")) org-babel-tangle-langs)))
> #+end_src
>

the above can be omitted entirely

If you've made it this far, then thanks for your patience, and please
let me know if you run into any problems with the above.

Best -- Eric

>
> which custimizes the shebang creation and the comments in the tangled file.
> Do I have to change any settings, and if yes, how? The previous conversation
> seems to say "yes, it needs to be changed", but I don't understand what and
> how.
>
>
> Thanks,
>
> Rainer.
> On Thu, Jun 24, 2010 at 6:27 PM, Eric Schulte <schulte.eric@gmail.com>wrote:
>
>> Hi Sébastien,
>>
>> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
>>
>> [...]
>> >
>> > For my own understanding, what's the status of `Org-babel-screen', for
>> which
>> > I've never been able to understand completely all the differences with
>> `sh' in
>> > `Org-babel'?
>> >
>>
>> I believe screen has more of a focus on sustained interaction with an
>> interactive terminal, although to be honest I haven't really used it and
>> can't say for sure.  Benjamin Andresen, the author, may have a more
>> satisfying answer for you.
>>
>> >
>> > Second, a problem with the following code:
>> >
>> >       ;; Org-babel needs to be told to recognize awk source code blocks
>> and
>> >       ;; how they should be tangled, which can be accomplished with the
>> >       ;; following:
>> >       (org-babel-add-interpreter "awk")
>> >       (add-to-list 'org-babel-tangle-langs '("awk" "awk"))
>> >
>> >       (org-babel-add-interpreter "fortran")
>> >       (add-to-list 'org-babel-tangle-langs '("fortran" "f"))
>> >
>> >       ;; ;; org-babel panics when trying to evaluate ruby code blocks
>> because
>> >       ;; ;; you don't have the required ruby executables available on
>> your
>> >       ;; ;; system. Probably the best way to deal with this is to remove
>> ruby
>> >       ;; ;; from the list of languages supported by babel:
>> >       ;; (setq org-babel-interpreters (delete "ruby"
>> org-babel-interpreters))
>> >
>> >       ;; make pre-built helper functions (`lob') available
>> >       ;; (org-babel-load-library-of-babel)
>> >
>> >       ;; mapping between languages (listings in LaTeX) and their major
>> mode
>> >       ;; (in Emacs)
>> >       (setq org-src-lang-modes
>> >             '(("ocaml" . tuareg)
>> >               ("elisp" . emacs-lisp)
>> >               ;; ("Delphi" . perl)
>> >               ("ditaa" . artist)
>> >               ("asymptote" . asy)
>> >               ("dot" . fundamental)))
>> >       ;; )
>> >
>> > Neither org-babel-add-interpreter, neither its shorter version do exist
>> now?
>> >
>>
>> Yes, thanks for bringing this up! I realized last night that I forgot to
>> mention this in the announcement.
>>
>> We have simplified the handling of languages in Org-babel, in that the
>> org-babel-interpreters and org-babel-tangle-langs variables have both
>> been removed.
>>
>> Rather than keeping explicit lists of supported languages, Babel will
>> now try to work with every language, and will only give up if it can't
>> find a needed function (e.g. if there is no org-babel-execute:foo
>> function defined then babel will give up on evaluating a foo code
>> block).  The only remaining language list is
>> `org-babel-tangle-lang-exts' which can optionally be used to associate
>> file extensions with language names, but is *not* required for
>> evaluation or tangling.
>>
>> Given this, your configuration from above could be rewritten as
>>
>> --8<---------------cut here---------------start------------->8---
>>       ;; Org-babel now needs less hand-holding :) however it could be
>>      ;; useful to know extensions for some languages
>>      (add-to-list 'org-babel-tangle-lang-exts '("fortran" . "f"))
>>
>>      ;; mapping between languages (listings in LaTeX) and their major mode
>>      ;; (in Emacs)
>>      (setq org-src-lang-modes
>>            '(("ocaml" . tuareg)
>>              ("elisp" . emacs-lisp)
>>              ;; ("Delphi" . perl)
>>              ("ditaa" . artist)
>>              ("asymptote" . asy)
>>              ("dot" . fundamental)))
>>      ;; )
>> --8<---------------cut here---------------end--------------->8---
>>
>> Cheers -- Eric
>>
>> >
>> > Best regards,
>> >   Seb
>>
>> _______________________________________________
>> 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
>>

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

[Štěpán Němec]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Rainer,
>
> First I'll give some expanded instructions in the hopes of helping out
> anyone else affected by my lack of good instructions in the announcement
> email.  Then I'll provide a re-write of your config below as an example.
>
> Babel took the integration into Org-mode as an opportunity to do some
> much needed house cleaning.  Most importantly we have cleared out
> unnecessary configuration variables -- which is great unless you already
> have these variables set.
>
> We have eliminated the two main internal lists of languages, namely
> - org-babel-interpreters and
> - org-babel-tangle-langs
> so any config lines which mention those variables, can/should be
> stripped out in their entirety.  This includes any calls to the
> `org-babl-add-interpreter' function, whose sole purpose was to add
> languages to the org-babel-interpreters variable.
>
> alright, so with those calls stripped out, we may still in some cases
> want to associate a file name extension with certain languages, for
> example we want all of our emacs-lisp files to end in a ".el", we can do
> this will the `org-babel-tangle-lang-exts' variable.  In general you
> shouldn't need to touch this as it already has defaults for most common
> languages, and if a language is not present in org-babel-tangle-langs,
> then babel will just use the language name, so for example a file of c
> code will have a ".c" extension by default, sh code will have a ".sh"
> extension ect...
>
> You also mentioned shebang lines.  This configuration now lives in
> header arguments.  So the shebang for a single file can be set at the
> code block level, e.g.
>
> #+begin_src clojure :shebang #!/usr/bin/env clj
>   (println "with a shebang line, I can be run as a script!")
> #+end_src
>
> note that whenever a file is tangled which includes a shebang line,
> org-babel will make the file executable, so there is good reason to only
> add shebangs at the source-code level.  However if you're sure that you
> want all of your code in some language (say shell scripts) to tangle out
> with shebang lines, then you can customize the default header arguments
> for that language, e.g.
>
> ;; ensure this variable is defined defined
> (unless (boundp 'org-babel-default-header-args:sh)
>   (setq org-babel-default-header-args:sh '()))
>
> ;; add a default shebang header argument
> (add-to-list 'org-babel-default-header-args:sh
>              '(:shebang . "#!/bin/bash"))
>
> The final change, is that to conform to Emacs guidelines, the prefix
> org-babel-* in all require lines, has been changed to ob-*, also, since
> Babel now loads by default with Org-mode you can remove any
>   (require 'org-babel)
> or 
>   (require 'org-babel-init)
> that may by lying around your configuration.
>
> Whew! that was alot of writing for a /simplification/ of configuration.
> Hopefully the example of your configuration below will be a more
> succinct demonstration of the needed transformations.
>
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
>> Hi
>>
>> First of all thanks for integrating Org-babel into Org-mode.
>>
>> But for the less fluent elisp and org-mode users, I am slightly confused in
>> the changes necessary on my side.
>>
>> I have the following in my emacs.org file:
>>
>>
>> #+begin_src emacs-lisp
>>   (require 'org-babel-R)         ;; requires R and ess-mode
>>   ;; (require 'org-babel-ruby)      ;; requires ruby, irb, ruby-mode, and
>> inf-ruby
>>   (require 'org-babel-python)    ;; requires python, and python-mode
>>   ;; (require 'org-babel-clojure)   ;; requires clojure, clojure-mode,
>> swank-clojure and slime
>> #+end_src
>
> the above becomes
>
> #+begin_src emacs-lisp
>   (require 'ob-R)
>   ;; (require 'ob-ruby)
>   (require 'ob-python)
>   ;; (require 'ob-clojure)
> #+end_src
>
>> 
>> *** Start babel
>> #+begin_src emacs-lisp
>>   (org-babel-load-library-of-babel)
>> #+end_src
>
> the above becomes
>
> #+begin_src emacs-lisp
>   (org-babel-lob-ingest "~/path/to/org/contrib/babel/library-of-babel.org")
> #+end_src
>
>> 
>> *** Customization of sh
>> set shebang for sh script to "#!/bin/bash" and exclude additional comments
>> (t)
>> #+begin_src emacs-lisp
>>   (setq org-babel-tangle-langs
>>   (cons
>>   '("sh" "sh" "#!/bin/bash" t)
>> (remove-if (lambda (el) (string= (car el) "sh")) org-babel-tangle-langs)))
>> #+end_src
>
> #+begin_src emacs-lisp
>   ;; ensure this variable is defined defined
>   (unless (boundp 'org-babel-default-header-args:sh)
>     (setq org-babel-default-header-args:sh '()))
>
>   ;; add a default shebang header argument
>   (add-to-list 'org-babel-default-header-args:sh
>                '(:shebang . "#!/bin/bash"))
> #+end_src
>
>> 
>> *** Customization of R
>>   set shebang for R script to "" and exclude additional comments (t)
>> #+begin_src emacs-lisp
>>   (setq org-babel-tangle-langs
>>   (cons
>>   '("R" "R")
>>   (remove-if (lambda (el) (string= (car el) "R")) org-babel-tangle-langs)))
>> #+end_src
>>
>
> the above can be omitted entirely
>
> If you've made it this far, then thanks for your patience, and please
> let me know if you run into any problems with the above.
>
> Best -- Eric

How come some of your rewrites above still use the `org-babel-' prefix?
(As a side note, I don't see what Emacs guidelines suggest `ob-' is more
appropriate than `org-babel-', and I would personally prefer to retain
the latter -- it's much more descriptive.)

    Štěpán

[snip]

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

[Eric Schulte]

Štěpán Němec <stepnem@gmail.com> writes:

[...]
>
> How come some of your rewrites above still use the `org-babel-' prefix?
> (As a side note, I don't see what Emacs guidelines suggest `ob-' is more
> appropriate than `org-babel-', and I would personally prefer to retain
> the latter -- it's much more descriptive.)
>
>     Štěpán
>

Hi Štěpán,

The guidelines I mentioned (I believe) specify that all file names for
emacs-lisp files which are part of Emacs must be unique in the first 6
or so characters.  This is why all "(require 'ob-*)" lines (which must
correspond to file names) now use ob-* instead of org-babel-*.  Since I
(like you) prefer the org-babel-* prefixes, those have been retained for
all function and variable names.

Hope this explains it, I'm certainly open to other naming suggestions.

Best -- Eric

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

[Štěpán Němec]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Štěpán Němec <stepnem@gmail.com> writes:
>
> [...]
>>
>> How come some of your rewrites above still use the `org-babel-' prefix?
>> (As a side note, I don't see what Emacs guidelines suggest `ob-' is more
>> appropriate than `org-babel-', and I would personally prefer to retain
>> the latter -- it's much more descriptive.)
>>
>>     Štěpán
>>
>
> Hi Štěpán,
>
> The guidelines I mentioned (I believe) specify that all file names for
> emacs-lisp files which are part of Emacs must be unique in the first 6
> or so characters.  This is why all "(require 'ob-*)" lines (which must
> correspond to file names) now use ob-* instead of org-babel-*.  Since I
> (like you) prefer the org-babel-* prefixes, those have been retained for
> all function and variable names.

I see. Hm... could you provide some source for that? The only
restriction on file names I can recall is this section from Appendix D
of the Emacs Lisp Reference Manual:

   * Please keep the names of your Emacs Lisp source files to 13
     characters or less.  This way, if the files are compiled, the
     compiled files' names will be 14 characters or less, which is
     short enough to fit on all kinds of Unix systems.
     
Is that perhaps what you meant? In any case, I see that the
recommendation I quote above would make the file renaming necessary,
too.

(Also, I believe you actually did mention renaming *functions*, which
created my confusion in the first place -- cf. the commit message of
e0e4d76094f26 for example.)

> Hope this explains it, I'm certainly open to other naming suggestions.

It would make a lot of sense to at least still begin the file names with
`org' IMHO, if at all possible.

    Štěpán

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

[Eric Schulte]

Štěpán Němec <stepnem@gmail.com> writes:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Štěpán Němec <stepnem@gmail.com> writes:
>>
>> [...]
>>>
>>> How come some of your rewrites above still use the `org-babel-' prefix?
>>> (As a side note, I don't see what Emacs guidelines suggest `ob-' is more
>>> appropriate than `org-babel-', and I would personally prefer to retain
>>> the latter -- it's much more descriptive.)
>>>
>>>     Štěpán
>>>
>>
>> Hi Štěpán,
>>
>> The guidelines I mentioned (I believe) specify that all file names for
>> emacs-lisp files which are part of Emacs must be unique in the first 6
>> or so characters.  This is why all "(require 'ob-*)" lines (which must
>> correspond to file names) now use ob-* instead of org-babel-*.  Since I
>> (like you) prefer the org-babel-* prefixes, those have been retained for
>> all function and variable names.
>
> I see. Hm... could you provide some source for that? The only
> restriction on file names I can recall is this section from Appendix D
> of the Emacs Lisp Reference Manual:
>
>    * Please keep the names of your Emacs Lisp source files to 13
>      characters or less.  This way, if the files are compiled, the
>      compiled files' names will be 14 characters or less, which is
>      short enough to fit on all kinds of Unix systems.
>      
> Is that perhaps what you meant? In any case, I see that the
> recommendation I quote above would make the file renaming necessary,
> too.
>

Maybe that is the ultimate source, this requirement came to me by way of
a recommendation from Carsten when we first discussed merging babel into
the Org-mode core.

>
> (Also, I believe you actually did mention renaming *functions*, which
> created my confusion in the first place -- cf. the commit message of
> e0e4d76094f26 for example.)
>

my bad.

>
>> Hope this explains it, I'm certainly open to other naming suggestions.
>
> It would make a lot of sense to at least still begin the file names with
> `org' IMHO, if at all possible.
>

hmm, the longest (non-language-specific) file name is already 12
characters long,

(length "ob-tangle.el") ;; => 12

which doesn't give us much room to play around with.  Looking at a
couple of possible prefixes, and the related leftover characters for
differentiating the *-tangle, *-comint, *-ref, etc... core babel files,
yields the following

| prefix   | remaining characters |
|----------+----------------------|
| ob-      |                    5 |
| org-b-   |                    2 |
| orgb-    |                    3 |
| org-bbl- |                    0 |
| bbl-     |                    4 |
| babel-   |                    2 |
#+TBLFM: $2='(sbe leftover (prefix $$1))

#+source: leftover
#+begin_src emacs-lisp :var prefix=""
  (-
   ;; length w/o .el
   (- 13 (length ".el"))
   ;; length of prefix
   (length prefix))
#+end_src

Personally, none of the above seem to be particularly superior to the
current naming scheme, given the fact that we need to fit multiple files
behind this prefix.

-- Eric

>
>     Štěpán

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

[Stephan Schmitt]

Also sprach Eric Schulte:
> Štěpán Němec<stepnem@gmail.com>  writes:
>
>> "Eric Schulte"<schulte.eric@gmail.com>  writes:
>>
>>> Štěpán Němec<stepnem@gmail.com>  writes:
>>>
>>> [...]
>>>>
>>>> How come some of your rewrites above still use the `org-babel-' prefix?
>>>> (As a side note, I don't see what Emacs guidelines suggest `ob-' is more
>>>> appropriate than `org-babel-', and I would personally prefer to retain
>>>> the latter -- it's much more descriptive.)
>>>>
>>>>      Štěpán
>>>>
>>>
[...]
>> The only restriction on file names I can recall is this section
>> from Appendix D of the Emacs Lisp Reference Manual:
>>
>>     * Please keep the names of your Emacs Lisp source files to 13
>>       characters or less.  This way, if the files are compiled, the
>>       compiled files' names will be 14 characters or less, which is
>>       short enough to fit on all kinds of Unix systems.
>>

Are there any unix systems running emacs 22 (iirc org-mode doesn't
support emacs 21 anymore) which have problems with long filenames?
We're living in the 21st century, aren't we?

[...]
>>
>> It would make a lot of sense to at least still begin the file names with
>> `org' IMHO, if at all possible.
>>
>
> hmm, the longest (non-language-specific) file name is already 12
> characters long,
>
> (length "ob-tangle.el") ;; =>  12
>
> which doesn't give us much room to play around with.  Looking at a
> couple of possible prefixes, and the related leftover characters for
> differentiating the *-tangle, *-comint, *-ref, etc... core babel files,
> yields the following
>
> | prefix   | remaining characters |
> |----------+----------------------|
> | ob-      |                    5 |
> | org-b-   |                    2 |
> | orgb-    |                    3 |
> | org-bbl- |                    0 |
> | bbl-     |                    4 |
> | babel-   |                    2 |
> #+TBLFM: $2='(sbe leftover (prefix $$1))
>
> #+source: leftover
> #+begin_src emacs-lisp :var prefix=""
>    (-
>     ;; length w/o .el
>     (- 13 (length ".el"))
>     ;; length of prefix
>     (length prefix))
> #+end_src
>
> Personally, none of the above seem to be particularly superior to the
> current naming scheme, given the fact that we need to fit multiple files
> behind this prefix.

I think you have to add 2 to each of the numbers above.
But the conclusion surely remains the same...

Greetings,
	Stephan

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

[Carsten Dominik]

On Jun 26, 2010, at 6:30 PM, Štěpán Němec wrote:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Štěpán Němec <stepnem@gmail.com> writes:
>>
>> [...]
>>>
>>> How come some of your rewrites above still use the `org-babel-'  
>>> prefix?
>>> (As a side note, I don't see what Emacs guidelines suggest `ob-'  
>>> is more
>>> appropriate than `org-babel-', and I would personally prefer to  
>>> retain
>>> the latter -- it's much more descriptive.)
>>>
>>>    Štěpán
>>>
>>
>> Hi Štěpán,
>>
>> The guidelines I mentioned (I believe) specify that all file names  
>> for
>> emacs-lisp files which are part of Emacs must be unique in the  
>> first 6
>> or so characters.  This is why all "(require 'ob-*)" lines (which  
>> must
>> correspond to file names) now use ob-* instead of org-babel-*.   
>> Since I
>> (like you) prefer the org-babel-* prefixes, those have been  
>> retained for
>> all function and variable names.
>
> I see. Hm... could you provide some source for that? The only
> restriction on file names I can recall is this section from Appendix D
> of the Emacs Lisp Reference Manual:
>
>   * Please keep the names of your Emacs Lisp source files to 13
>     characters or less.  This way, if the files are compiled, the
>     compiled files' names will be 14 characters or less, which is
>     short enough to fit on all kinds of Unix systems.

This is a restriction from the compiler.

However, Emacs wants to be installable on many systems, including MS- 
DOS, which has only 8+3 character file names.  Therefore, Emacs  
requires that the names are unique in the first 8 letters - they may  
be longer than 8, but they must be unique when shortened.

I cannot find the reference now, but I did explicitly ask a short  
while ago and got this confirmed by Stefan Monnier.

>
> Is that perhaps what you meant? In any case, I see that the
> recommendation I quote above would make the file renaming necessary,
> too.
>
> (Also, I believe you actually did mention renaming *functions*, which
> created my confusion in the first place -- cf. the commit message of
> e0e4d76094f26 for example.)
>
>> Hope this explains it, I'm certainly open to other naming  
>> suggestions.
>
> It would make a lot of sense to at least still begin the file names  
> with
> `org' IMHO, if at all possible.

This will not solve the problem, I fear.

- Carsten

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

[Štěpán Němec]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On Jun 26, 2010, at 6:30 PM, Štěpán Němec wrote:
>
>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>
>>> Štěpán Němec <stepnem@gmail.com> writes:
>>>
>>> [...]
>>>>
>>>> How come some of your rewrites above still use the `org-babel-' 
>>>> prefix?
>>>> (As a side note, I don't see what Emacs guidelines suggest `ob-' 
>>>> is more
>>>> appropriate than `org-babel-', and I would personally prefer to retain
>>>> the latter -- it's much more descriptive.)
>>>>
>>>>    Štěpán
>>>>
>>>
>>> Hi Štěpán,
>>>
>>> The guidelines I mentioned (I believe) specify that all file names for
>>> emacs-lisp files which are part of Emacs must be unique in the first 6
>>> or so characters.  This is why all "(require 'ob-*)" lines (which must
>>> correspond to file names) now use ob-* instead of org-babel-*.  Since I
>>> (like you) prefer the org-babel-* prefixes, those have been retained for
>>> all function and variable names.
>>
>> I see. Hm... could you provide some source for that? The only
>> restriction on file names I can recall is this section from Appendix D
>> of the Emacs Lisp Reference Manual:
>>
>>   * Please keep the names of your Emacs Lisp source files to 13
>>     characters or less.  This way, if the files are compiled, the
>>     compiled files' names will be 14 characters or less, which is
>>     short enough to fit on all kinds of Unix systems.
>
> This is a restriction from the compiler.
>
> However, Emacs wants to be installable on many systems, including MS-
> DOS, which has only 8+3 character file names.  Therefore, Emacs requires that
> the names are unique in the first 8 letters - they may  be longer than 8, but
> they must be unique when shortened.
>
> I cannot find the reference now, but I did explicitly ask a short while ago
> and got this confirmed by Stefan Monnier.

Ah, right, I remember that, yes. MS-DOG strikes again.

>> Is that perhaps what you meant? In any case, I see that the
>> recommendation I quote above would make the file renaming necessary,
>> too.
>>
>> (Also, I believe you actually did mention renaming *functions*, which
>> created my confusion in the first place -- cf. the commit message of
>> e0e4d76094f26 for example.)
>>
>>> Hope this explains it, I'm certainly open to other naming suggestions.
>>
>> It would make a lot of sense to at least still begin the file names with
>> `org' IMHO, if at all possible.
>
> This will not solve the problem, I fear.

Indeed. In this light `ob-' looks more like "as good as it gets".


Štěpán

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

[Rainer M Krug]

[-- Attachment #1.1: Type: text/plain, Size: 12112 bytes --]

On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> Hi Rainer,
>

Hi Eric


>
> First I'll give some expanded instructions in the hopes of helping out
> anyone else affected by my lack of good instructions in the announcement
> email.  Then I'll provide a re-write of your config below as an example.
>

Sounds perfect.


>
> Babel took the integration into Org-mode as an opportunity to do some
> much needed house cleaning.  Most importantly we have cleared out
> unnecessary configuration variables -- which is great unless you already
> have these variables set.
>
> We have eliminated the two main internal lists of languages, namely
> - org-babel-interpreters and
> - org-babel-tangle-langs
> so any config lines which mention those variables, can/should be
> stripped out in their entirety.  This includes any calls to the
> `org-babl-add-interpreter' function, whose sole purpose was to add
> languages to the org-babel-interpreters variable.
>

OK - I understand that and it makes perfect sense.


> alright, so with those calls stripped out, we may still in some cases
> want to associate a file name extension with certain languages, for
> example we want all of our emacs-lisp files to end in a ".el", we can do
> this will the `org-babel-tangle-lang-exts' variable.  In general you
> shouldn't need to touch this as it already has defaults for most common
> languages, and if a language is not present in org-babel-tangle-langs,
> then babel will just use the language name, so for example a file of c
> code will have a ".c" extension by default, sh code will have a ".sh"
> extension ect...
>

Perfect.


>
> You also mentioned shebang lines.  This configuration now lives in
> header arguments.  So the shebang for a single file can be set at the
> code block level, e.g.
>
> #+begin_src clojure :shebang #!/usr/bin/env clj
>  (println "with a shebang line, I can be run as a script!")
> #+end_src
>

That's perfect - it adds much flexibility, and to do it via header arguments
is absolutely perfect for me.


>
> note that whenever a file is tangled which includes a shebang line,
> org-babel will make the file executable, so there is good reason to only
>

Wow - even better!


> add shebangs at the source-code level.  However if you're sure that you
> want all of your code in some language (say shell scripts) to tangle out
> with shebang lines, then you can customize the default header arguments
> for that language, e.g.
>
> ;; ensure this variable is defined defined
> (unless (boundp 'org-babel-default-header-args:sh)
>  (setq org-babel-default-header-args:sh '()))
>
> ;; add a default shebang header argument
> (add-to-list 'org-babel-default-header-args:sh
>             '(:shebang . "#!/bin/bash"))
>

Good to know, but in general I am perfectly happy without shebang lines. But
there are cases, where they are necessary.


>
> The final change, is that to conform to Emacs guidelines, the prefix
> org-babel-* in all require lines, has been changed to ob-*, also, since
> Babel now loads by default with Org-mode you can remove any
>  (require 'org-babel)
> or
>  (require 'org-babel-init)
> that may by lying around your configuration.
>

OK - understood.


>
> Whew! that was alot of writing for a /simplification/ of configuration.
>

Well - but it made many things much clearer for me. It is often more
difficult to explain the changes which need to be made then to explain to a
new user how it should be done.


> Hopefully the example of your configuration below will be a more
> succinct demonstration of the needed transformations.
>
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > Hi
> >
> > First of all thanks for integrating Org-babel into Org-mode.
> >
> > But for the less fluent elisp and org-mode users, I am slightly confused
> in
> > the changes necessary on my side.
> >
> > I have the following in my emacs.org file:
> >
> >
> > #+begin_src emacs-lisp
> >   (require 'org-babel-R)         ;; requires R and ess-mode
> >   ;; (require 'org-babel-ruby)      ;; requires ruby, irb, ruby-mode, and
> > inf-ruby
> >   (require 'org-babel-python)    ;; requires python, and python-mode
> >   ;; (require 'org-babel-clojure)   ;; requires clojure, clojure-mode,
> > swank-clojure and slime
> > #+end_src
>
> the above becomes
>
> #+begin_src emacs-lisp
>  (require 'ob-R)
>  ;; (require 'ob-ruby)
>  (require 'ob-python)
>  ;; (require 'ob-clojure)
> #+end_src
>

OK - done.


>
> >
> > *** Start babel
> > #+begin_src emacs-lisp
> >   (org-babel-load-library-of-babel)
> > #+end_src
>
> the above becomes
>
> #+begin_src emacs-lisp
>  (org-babel-lob-ingest "~/path/to/org/contrib/babel/library-of-babel.org")
> #+end_src
>

I don't seem to need this line anymore -  it is working without. Also, I
don't remember why I put it in...


> >
> > *** Customization of sh
> >   set shebang for sh script to "#!/bin/bash" and exclude additional
> comments
> > (t)
> > #+begin_src emacs-lisp
> >   (setq org-babel-tangle-langs
> >   (cons
> >   '("sh" "sh" "#!/bin/bash" t)
> >   (remove-if (lambda (el) (string= (car el) "sh"))
> org-babel-tangle-langs)))
> > #+end_src
>
> #+begin_src emacs-lisp
>  ;; ensure this variable is defined defined
>  (unless (boundp 'org-babel-default-header-args:sh)
>    (setq org-babel-default-header-args:sh '()))
>
>  ;; add a default shebang header argument
>  (add-to-list 'org-babel-default-header-args:sh
>               '(:shebang . "#!/bin/bash"))
> #+end_src
>
> >
> > *** Customization of R
> >   set shebang for R script to "" and exclude additional comments (t)
> > #+begin_src emacs-lisp
> >   (setq org-babel-tangle-langs
> >   (cons
> >   '("R" "R")
> >   (remove-if (lambda (el) (string= (car el) "R"))
> org-babel-tangle-langs)))
> > #+end_src
> >
>
> the above can be omitted entirely
>
> If you've made it this far, then thanks for your patience,


I have to thank you for the patience to write such a clear description. I
must say I enjoyed reading it. I would actually suggest to put this up on
the WiKi for org-babel, as it can help change ones configuration, but also
to understand how to configure the integrated org-babel - Thanks a lot.


> and please let me know if you run into any problems with the above.
>

Thanks again - it is working.

 Just one additional question: When I go on the menu to Org -- Documentation
-- Info Documentation, I still get the info help from version 6.21b,
although I installed the version from git, and under Org -- Documentation --
Show Version it gives me "Org-mode version 6.36trans
(release_6.36.408.g7f21f)".

Can I change this somehow? It seems that the Info Documentation is the one
which is part of emacs.

Cheers,

Rainer


>
> Best -- Eric
>
> >
> > which custimizes the shebang creation and the comments in the tangled
> file.
> > Do I have to change any settings, and if yes, how? The previous
> conversation
> > seems to say "yes, it needs to be changed", but I don't understand what
> and
> > how.
> >
> >
> > Thanks,
> >
> > Rainer.
> > On Thu, Jun 24, 2010 at 6:27 PM, Eric Schulte <schulte.eric@gmail.com
> >wrote:
> >
> >> Hi Sébastien,
> >>
> >> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
> >>
> >> [...]
> >> >
> >> > For my own understanding, what's the status of `Org-babel-screen', for
> >> which
> >> > I've never been able to understand completely all the differences with
> >> `sh' in
> >> > `Org-babel'?
> >> >
> >>
> >> I believe screen has more of a focus on sustained interaction with an
> >> interactive terminal, although to be honest I haven't really used it and
> >> can't say for sure.  Benjamin Andresen, the author, may have a more
> >> satisfying answer for you.
> >>
> >> >
> >> > Second, a problem with the following code:
> >> >
> >> >       ;; Org-babel needs to be told to recognize awk source code
> blocks
> >> and
> >> >       ;; how they should be tangled, which can be accomplished with
> the
> >> >       ;; following:
> >> >       (org-babel-add-interpreter "awk")
> >> >       (add-to-list 'org-babel-tangle-langs '("awk" "awk"))
> >> >
> >> >       (org-babel-add-interpreter "fortran")
> >> >       (add-to-list 'org-babel-tangle-langs '("fortran" "f"))
> >> >
> >> >       ;; ;; org-babel panics when trying to evaluate ruby code blocks
> >> because
> >> >       ;; ;; you don't have the required ruby executables available on
> >> your
> >> >       ;; ;; system. Probably the best way to deal with this is to
> remove
> >> ruby
> >> >       ;; ;; from the list of languages supported by babel:
> >> >       ;; (setq org-babel-interpreters (delete "ruby"
> >> org-babel-interpreters))
> >> >
> >> >       ;; make pre-built helper functions (`lob') available
> >> >       ;; (org-babel-load-library-of-babel)
> >> >
> >> >       ;; mapping between languages (listings in LaTeX) and their major
> >> mode
> >> >       ;; (in Emacs)
> >> >       (setq org-src-lang-modes
> >> >             '(("ocaml" . tuareg)
> >> >               ("elisp" . emacs-lisp)
> >> >               ;; ("Delphi" . perl)
> >> >               ("ditaa" . artist)
> >> >               ("asymptote" . asy)
> >> >               ("dot" . fundamental)))
> >> >       ;; )
> >> >
> >> > Neither org-babel-add-interpreter, neither its shorter version do
> exist
> >> now?
> >> >
> >>
> >> Yes, thanks for bringing this up! I realized last night that I forgot to
> >> mention this in the announcement.
> >>
> >> We have simplified the handling of languages in Org-babel, in that the
> >> org-babel-interpreters and org-babel-tangle-langs variables have both
> >> been removed.
> >>
> >> Rather than keeping explicit lists of supported languages, Babel will
> >> now try to work with every language, and will only give up if it can't
> >> find a needed function (e.g. if there is no org-babel-execute:foo
> >> function defined then babel will give up on evaluating a foo code
> >> block).  The only remaining language list is
> >> `org-babel-tangle-lang-exts' which can optionally be used to associate
> >> file extensions with language names, but is *not* required for
> >> evaluation or tangling.
> >>
> >> Given this, your configuration from above could be rewritten as
> >>
> >> --8<---------------cut here---------------start------------->8---
> >>       ;; Org-babel now needs less hand-holding :) however it could be
> >>      ;; useful to know extensions for some languages
> >>      (add-to-list 'org-babel-tangle-lang-exts '("fortran" . "f"))
> >>
> >>      ;; mapping between languages (listings in LaTeX) and their major
> mode
> >>      ;; (in Emacs)
> >>      (setq org-src-lang-modes
> >>            '(("ocaml" . tuareg)
> >>              ("elisp" . emacs-lisp)
> >>              ;; ("Delphi" . perl)
> >>              ("ditaa" . artist)
> >>              ("asymptote" . asy)
> >>              ("dot" . fundamental)))
> >>      ;; )
> >> --8<---------------cut here---------------end--------------->8---
> >>
> >> Cheers -- Eric
> >>
> >> >
> >> > Best regards,
> >> >   Seb
> >>
> >> _______________________________________________
> >> 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
> >>
>



-- 
NEW GERMAN FAX NUMBER!!!

Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Cell:           +27 - (0)83 9479 042
Fax:            +27 - (0)86 516 2782
Fax:            +49 - (0)321 2125 2244
email:          Rainer@krugs.de

Skype:          RMkrug
Google:         R.M.Krug@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 17074 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Christopher Witte]

[-- Attachment #1: Type: text/plain, Size: 3418 bytes --]

I'm having trouble getting the new version of babel to work with
haskell and R under Ubuntu 10.04 using emacs-snapshot.  It works fine
for emacs-lisp.  I had to change the variable LISPF in the Makefile
to:

LISPF      = 	org.el				\
.....
		babel/ob.el			\
		babel/ob-table.el		\
		babel/ob-lob.el			\
		babel/ob-ref.el			\
		babel/ob-exp.el			\
		babel/ob-tangle.el		\
		babel/ob-comint.el		\
		babel/ob-keys.el		\
		babel/langs/ob-emacs-lisp.el	\
		babel/langs/ob-haskell.el	\
		babel/langs/ob-latex.el	\
		babel/langs/ob-sh.el	\
		babel/langs/ob-asymptote.el	\
		babel/langs/ob-R.el	\
		babel/langs/ob-gnuplot.el	

otherwise I couldn't compile my .emacs file, which contains the following:

(require 'org-install)

;;(require 'org)
;;(require 'ob)
;;(require 'ob-tangle)
;; org-babel set up
(require 'ob-haskell)
(require 'ob-latex)
(require 'ob-sh)
(require 'ob-asymptote)
(require 'ob-R)
(require 'ob-gnuplot)

The following works fine:
          #+tblname: example-table
          | 1 |
          | 2 |
          | 3 |
          | 4 |

          #+source: table-length
          #+begin_src emacs-lisp  :var table=example-table
          (length table)
          #+end_src

          #+results: table-length
	  : 4

But when I try the haskell equivalent:
          #+source: table-length
          #+begin_src haskell  :var table=example-table
          length table
          #+end_src


I get:
executing haskell source code block
reference 'example-table' not found in this buffer
org-babel-ref-resolve-reference: reference 'example-table' not found
in this buffer

If I try:
          #+source: table-length
          #+begin_src haskell
          length [1,2,3]
          #+end_src


I get:
executing haskell source code block
org-babel-execute:haskell: Symbol's function definition is void: session


I also get a lot of warnings when I compile org-mode, see the attached
buiild log.


Thanks for your help,

Chris Witte.

On 23 June 2010 23:09, Eric Schulte <schulte.eric@gmail.com> wrote:
> Hi,
>
> I've just merged the babel branch into the main branch of Org-mode.
> This merge culminates much integration work by Dan Davison and Tom Dye,
> as well as myself.
>
> Babel is now part of Org-mode.
>
> The biggest changes are:
>
> 1) Babel now has documentation!  It is part of Org-mode's documentation
>
>   see Chapter 14 _Working With Source Code_
>
>   also, the Babel keybindings are now listed in the refcard, and can be
>   viewed from any Org-mode buffer by pressing C-c C-v h
>
> 2) Babel will now be loaded by default along with the rest of Org-mode.
>   This means that *everyone* currently using babel will need to change
>   their Emacs config and remove the (require 'org-babel-int) and/or
>   (require 'org-babel) lines.
>
>   Support for evaluating emacs-lisp code blocks is loaded by default.
>   All other languages will need to be required explicitly.  To conform
>   to Emacs filename specifications all language require lines have been
>   shortened from e.g.
>
>   (require 'org-babel-sh)
>
>   to
>
>   (require 'ob-sh)
>
> Thanks -- 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
>

[-- Attachment #2: build.log --]
[-- Type: text/x-log, Size: 34113 bytes --]

emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org.el

In org-order-calendar-date-args:
org.el:14428:31:Warning: `european-calendar-style' is an obsolete variable (as
    of Emacs 23.1); use `calendar-date-style' instead.
Wrote /home/cwitte/source/elisp/org-mode/lisp/org.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-agenda.el

In org-agenda-add-entry-to-org-agenda-diary-file:
org-agenda.el:7160:42:Warning: `european-calendar-style' is an obsolete
    variable (as of Emacs 23.1); use `calendar-date-style' instead.
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-agenda.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-ascii.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-ascii.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-attach.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-attach.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-archive.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-archive.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-bbdb.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-bbdb.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-beamer.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-beamer.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-bibtex.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-bibtex.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-capture.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-capture.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-clock.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-clock.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-colview.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-colview.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-colview-xemacs.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-colview-xemacs.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-compat.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-compat.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-crypt.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-crypt.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-ctags.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-ctags.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-datetree.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-datetree.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-docview.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-docview.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-entities.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-entities.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-exp.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-exp.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-exp-blocks.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-exp-blocks.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-docbook.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-docbook.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-faces.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-faces.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-feed.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-feed.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-footnote.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-footnote.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-freemind.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-freemind.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-gnus.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-gnus.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-habit.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-habit.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-html.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-html.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-icalendar.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-icalendar.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-id.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-id.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-indent.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-indent.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-info.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-info.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-inlinetask.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-inlinetask.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-jsinfo.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-jsinfo.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-irc.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-irc.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-latex.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-latex.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-list.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-list.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-mac-message.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-mac-message.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-macs.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-macs.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-mew.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-mew.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-mhe.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-mhe.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-mks.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-mks.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-mobile.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-mobile.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-mouse.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-mouse.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-publish.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-publish.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-plot.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-plot.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-protocol.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-protocol.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-remember.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-remember.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-rmail.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-rmail.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-src.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-src.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-table.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-table.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-taskjuggler.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-taskjuggler.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-timer.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-timer.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-vm.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-vm.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-w3m.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-w3m.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-wl.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-wl.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-xoxo.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-xoxo.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob-table.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob-table.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob-lob.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob-lob.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob-ref.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob-ref.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob-exp.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob-exp.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob-tangle.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob-tangle.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob-comint.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob-comint.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/ob-keys.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/ob-keys.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/langs/ob-emacs-lisp.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/langs/ob-emacs-lisp.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/langs/ob-haskell.el

In org-babel-expand-body:haskell:
ob-haskell.el:55:61:Warning: malformed let binding: `(nth 1 (or
    processed-params (org-babel-process-params params)))'

In org-babel-haskell-export-to-lhs:
ob-haskell.el:164:28:Warning: reference to free variable
    `org-src-preserve-indentation'

In end of data:
ob-haskell.el:209:1:Warning: the following functions are not known to be
    defined: first, org-babel-comint-with-output, session, case, output,
    value, org-babel-ref-variables, org-babel-ruby-var-to-ruby,
    org-remove-indentation
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/langs/ob-haskell.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/langs/ob-latex.el

In org-babel-execute:latex:
ob-latex.el:66:22:Warning: reference to free variable
    `org-export-latex-packages-alist'
ob-latex.el:70:26:Warning: reference to free variable
    `org-format-latex-options'

In org-babel-latex-body-to-tex-file:
ob-latex.el:87:16:Warning: reference to free variable
    `org-format-latex-header'
ob-latex.el:90:17:Warning: reference to free variable
    `org-export-latex-default-packages-alist'
ob-latex.el:91:16:Warning: reference to free variable
    `org-export-latex-packages-alist'
ob-latex.el:92:16:Warning: reference to free variable
    `org-format-latex-header-extra'

In org-babel-latex-tex-to-pdf:
ob-latex.el:108:16:Warning: reference to free variable
    `org-latex-to-pdf-process'
ob-latex.el:129:13:Warning: reference to free variable
    `org-export-pdf-remove-logfiles'
ob-latex.el:130:22:Warning: reference to free variable
    `org-export-pdf-logfiles'

In end of data:
ob-latex.el:144:1:Warning: the following functions are not known to be
    defined: org-create-formula-image, org-splice-latex-header, remove-if,
    org-export-latex-fix-inputenc
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/langs/ob-latex.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/langs/ob-sh.el

In end of data:
ob-sh.el:203:1:Warning: the function `session' is not known to be defined.
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/langs/ob-sh.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/langs/ob-asymptote.el

In end of data:
ob-asymptote.el:158:1:Warning: the following functions are not known to be
    defined: orgtbl-to-generic, org-combine-plists
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/langs/ob-asymptote.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/langs/ob-R.el

In org-babel-R-evaluate:
ob-R.el:174:70:Warning: `(extractor (el) (if (or broke (and (string-match
    (regexp-quote org-babel-R-eoe-output) el) (setq broke t))) nil (if (=
    (length el) 0) nil (if (string-match comint-prompt-regexp el)
    (org-babel-trim (substring el (match-end 0))) el))))' is a malformed
    function
ob-R.el:216:23:Warning: reference to free variable
    `inferior-ess-primary-prompt'
ob-R.el:218:23:Warning: reference to free variable
    `inferior-ess-secondary-prompt'

In end of data:
ob-R.el:256:1:Warning: the following functions are not known to be defined:
    first, org-babel-ref-variables, org-babel-comint-in-buffer,
    comint-send-input, org-babel-comint-wait-for-output, orgtbl-to-tsv,
    org-babel-comint-buffer-livep, R, case, output, value,
    org-babel-comint-with-output, session, inferior-ess-send-input, flet
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/langs/ob-R.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/babel/langs/ob-gnuplot.el

In org-babel-expand-body:gnuplot:
ob-gnuplot.el:66:61:Warning: `(add-to-body (text) (setq body (concat text "
" body)))' is a malformed function

In org-babel-execute:gnuplot:
ob-gnuplot.el:140:22:Warning: assignment to free variable `output'
ob-gnuplot.el:146:11:Warning: reference to free variable `output'

In org-babel-gnuplot-quote-tsv-field:
ob-gnuplot.el:189:21:Warning: reference to free variable
    `org-table-number-regexp'
ob-gnuplot.el:190:23:Warning: reference to free variable `org-ts-regexp3'

In end of data:
ob-gnuplot.el:214:1:Warning: the following functions are not known to be
    defined: org-babel-ref-variables, flet, add-to-body,
    org-babel-comint-in-buffer, org-babel-comint-wait-for-output,
    org-time-string-to-time, orgtbl-to-generic, org-combine-plists
Wrote /home/cwitte/source/elisp/org-mode/lisp/babel/langs/ob-gnuplot.elc
emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"langs\" (expand-file-name \"babel\" (expand-file-name \"./lisp/\"))) (cons (expand-file-name \"babel\" (expand-file-name \"./lisp/\")) (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))))" -f batch-byte-compile lisp/org-install.el
Wrote /home/cwitte/source/elisp/org-mode/lisp/org-install.elc

[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Štěpán Němec]

Rainer M Krug <r.m.krug@gmail.com> writes:

>  Just one additional question: When I go on the menu to Org -- Documentation
> -- Info Documentation, I still get the info help from version 6.21b,
> although I installed the version from git, and under Org -- Documentation --
> Show Version it gives me "Org-mode version 6.36trans
> (release_6.36.408.g7f21f)".
>
> Can I change this somehow? It seems that the Info Documentation is the one
> which is part of emacs.

That depends on your Emacs installation specifics. In short, the problem
is that the directory containing the older Org documentation comes first
in `Info-directory-list'. Reading the docstrings for this variable as
well as `Info-default-directory-list' should give you enough information
to come up with a solution suitable for your configuration.

HTH,

Štěpán

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

[Rainer M Krug]

[-- Attachment #1.1: Type: text/plain, Size: 1689 bytes --]

On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec <stepnem@gmail.com> wrote:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> >  Just one additional question: When I go on the menu to Org --
> Documentation
> > -- Info Documentation, I still get the info help from version 6.21b,
> > although I installed the version from git, and under Org -- Documentation
> --
> > Show Version it gives me "Org-mode version 6.36trans
> > (release_6.36.408.g7f21f)".
> >
> > Can I change this somehow? It seems that the Info Documentation is the
> one
> > which is part of emacs.
>
> That depends on your Emacs installation specifics. In short, the problem
> is that the directory containing the older Org documentation comes first
> in `Info-directory-list'. Reading the docstrings for this variable as
> well as `Info-default-directory-list' should give you enough information
> to come up with a solution suitable for your configuration.
>

Thanks - I think I just have to add the directory in which the  info files
reside from the currently used org mode. Am I correct in assuming that
is ~/.emacs.d/org-mode/doc ?



> HTH,
>
> Štěpán
>



-- 
NEW GERMAN FAX NUMBER!!!

Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Cell:           +27 - (0)83 9479 042
Fax:            +27 - (0)86 516 2782
Fax:            +49 - (0)321 2125 2244
email:          Rainer@krugs.de

Skype:          RMkrug
Google:         R.M.Krug@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 2456 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Bernt Hansen]

Rainer M Krug <r.m.krug@gmail.com> writes:

> On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec <stepnem@gmail.com> wrote:
>
>     Rainer M Krug <r.m.krug@gmail.com> writes:
>    
>     >  Just one additional question: When I go on the menu to Org -- Documentation
>     > -- Info Documentation, I still get the info help from version 6.21b,
>     > although I installed the version from git, and under Org -- Documentation --
>     > Show Version it gives me "Org-mode version 6.36trans
>     > (release_6.36.408.g7f21f)".
>     >
>     > Can I change this somehow? It seems that the Info Documentation is the one
>     > which is part of emacs.
>    
>     That depends on your Emacs installation specifics. In short, the problem
>     is that the directory containing the older Org documentation comes first
>     in `Info-directory-list'. Reading the docstrings for this variable as
>     well as `Info-default-directory-list' should give you enough information
>     to come up with a solution suitable for your configuration.
>
> Thanks - I think I just have to add the directory in which the  info
> files reside from the currently used org mode. Am I correct in
> assuming that is ~/.emacs.d/org-mode/doc ?

This is how I did it.  It requires an emacs restart to pick up the new
directory.

http://doc.norang.ca/org-mode.html#InfoDocumentation

-Bernt

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

[Rainer M Krug]

[-- Attachment #1.1: Type: text/plain, Size: 2542 bytes --]

2010/6/28 Bernt Hansen <bernt@norang.ca>

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec <stepnem@gmail.com> wrote:
> >
> >     Rainer M Krug <r.m.krug@gmail.com> writes:
> >
> >     >  Just one additional question: When I go on the menu to Org --
> Documentation
> >     > -- Info Documentation, I still get the info help from version
> 6.21b,
> >     > although I installed the version from git, and under Org --
> Documentation --
> >     > Show Version it gives me "Org-mode version 6.36trans
> >     > (release_6.36.408.g7f21f)".
> >     >
> >     > Can I change this somehow? It seems that the Info Documentation is
> the one
> >     > which is part of emacs.
> >
> >     That depends on your Emacs installation specifics. In short, the
> problem
> >     is that the directory containing the older Org documentation comes
> first
> >     in `Info-directory-list'. Reading the docstrings for this variable as
> >     well as `Info-default-directory-list' should give you enough
> information
> >     to come up with a solution suitable for your configuration.
> >
> > Thanks - I think I just have to add the directory in which the  info
> > files reside from the currently used org mode. Am I correct in
> > assuming that is ~/.emacs.d/org-mode/doc ?
>
> This is how I did it.  It requires an emacs restart to pick up the new
> directory.
>
> http://doc.norang.ca/org-mode.html#InfoDocumentation


Thanks - that is adding the path to the variable Info-default-directory-list

It is working now:

I updated my org-mode directory with the following script:

rkrug@ecolmod:~/.emacs.d$ cat update_org-mode-git
#!/bin/sh
cd ./org-mode-git
cd org-mode

# git clone git://repo.or.cz/org-mode.git
git pull
git gc

make clean
make
make doc


after adding

make info

to the script, it is working now nicely.

Is there any other make I should do?

Thanks a lot,

Rainer


>
> -Bernt
>



-- 
NEW GERMAN FAX NUMBER!!!

Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Cell:           +27 - (0)83 9479 042
Fax:            +27 - (0)86 516 2782
Fax:            +49 - (0)321 2125 2244
email:          Rainer@krugs.de

Skype:          RMkrug
Google:         R.M.Krug@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 5036 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Bernt Hansen]

Rainer M Krug <r.m.krug@gmail.com> writes:

> I updated my org-mode directory with the following script:
>
> rkrug@ecolmod:~/.emacs.d$ cat update_org-mode-git
> #!/bin/sh
> cd ./org-mode-git
> cd org-mode 
>
> # git clone git://repo.or.cz/org-mode.git
> git pull
> git gc
>
> make clean
> make
> make doc
>
> after adding 
>
> make info
>
> to the script, it is working now nicely.
>
> Is there any other make I should do? 
>
> Thanks a lot,

Hi Rainer,

Short version: I don't think so.

Longer version:

I only do

    make doc/org.info

occasionally.  I don't bother with any other make targets -- I run
org-mode directly from the sources.

I used to compile all of the files but found it more tedious to do
updates (I update almost every day) and I didn't notice any speed
difference in my use of emacs and org-mode between the compiled and
uncompiled versions.  I normally leave my emacs session running for
days.

Regards,
Bernt

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

[Rainer M Krug]

[-- Attachment #1.1: Type: text/plain, Size: 1835 bytes --]

2010/6/28 Bernt Hansen <bernt@norang.ca>

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > I updated my org-mode directory with the following script:
> >
> > rkrug@ecolmod:~/.emacs.d$ cat update_org-mode-git
> > #!/bin/sh
> > cd ./org-mode-git
> > cd org-mode
> >
> > # git clone git://repo.or.cz/org-mode.git
> > git pull
> > git gc
> >
> > make clean
> > make
> > make doc
> >
> > after adding
> >
> > make info
> >
> > to the script, it is working now nicely.
> >
> > Is there any other make I should do?
> >
> > Thanks a lot,
>
> Hi Rainer,
>
> Short version: I don't think so.
>
> Longer version:
>
> I only do
>
>    make doc/org.info
>
> occasionally.  I don't bother with any other make targets -- I run
> org-mode directly from the sources.
>
> I used to compile all of the files but found it more tedious to do
> updates (I update almost every day) and I didn't notice any speed
> difference in my use of emacs and org-mode between the compiled and
> uncompiled versions.  I normally leave my emacs session running for
> days.
>

I don't know if it is a speed differences - I just followed the infos on the
org-mode website. Asnd as I have a script which is doing everything (and I
close my emacs sessions in the evenings), it is no problem for me.

Thanks for the help and

Cheers,

Rainer

>
> Regards,
> Bernt
>



-- 
NEW GERMAN FAX NUMBER!!!

Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Cell:           +27 - (0)83 9479 042
Fax:            +27 - (0)86 516 2782
Fax:            +49 - (0)321 2125 2244
email:          Rainer@krugs.de

Skype:          RMkrug
Google:         R.M.Krug@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 2910 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Eric Schulte]

Hi Rainer,

I'm happy this was useful

Rainer M Krug <r.m.krug@gmail.com> writes:

> On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

[...]
>> >
>> > *** Start babel
>> > #+begin_src emacs-lisp
>> >   (org-babel-load-library-of-babel)
>> > #+end_src
>>
>> the above becomes
>>
>> #+begin_src emacs-lisp
>>  (org-babel-lob-ingest "~/path/to/org/contrib/babel/library-of-babel.org")
>> #+end_src
>>
>
> I don't seem to need this line anymore -  it is working without. Also, I
> don't remember why I put it in...
>

The `org-babel-lob-ingest' function is used to load the source-code
blocks defined in an Org-mode file into the global
`org-babel-library-of-babel' variable.  The functions defined in this
variable can be called from any Org-mode file.  This makes it possible
to build a set of often-used generally applicable source-code blocks.

The idea behind the library-of-babel.org file distributed with Org-mode
is to share such functions throughout the entire Org-mode community.

Best -- Eric

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

[Eric Schulte]

Hi Christopher,

Christopher Witte <chris@witte.net.au> writes:

> I'm having trouble getting the new version of babel to work with
> haskell and R under Ubuntu 10.04 using emacs-snapshot.  It works fine
> for emacs-lisp.  I had to change the variable LISPF in the Makefile
> to:
>
> LISPF      = 	org.el				\
> .....
> 		babel/ob.el			\
> 		babel/ob-table.el		\
> 		babel/ob-lob.el			\
> 		babel/ob-ref.el			\
> 		babel/ob-exp.el			\
> 		babel/ob-tangle.el		\
> 		babel/ob-comint.el		\
> 		babel/ob-keys.el		\
> 		babel/langs/ob-emacs-lisp.el	\
> 		babel/langs/ob-haskell.el	\
> 		babel/langs/ob-latex.el	\
> 		babel/langs/ob-sh.el	\
> 		babel/langs/ob-asymptote.el	\
> 		babel/langs/ob-R.el	\
> 		babel/langs/ob-gnuplot.el	
>
> otherwise I couldn't compile my .emacs file, which contains the following:
>

Hmm, I would think it would be possible to require files which are not
byte-compiled.  The reason that the language files (aside from
emacs-lisp) are not compiled by default is that they often have exotic
requirements which will not be present on most users systems.

>
> (require 'org-install)
>
> ;;(require 'org)
> ;;(require 'ob)
> ;;(require 'ob-tangle)
> ;; org-babel set up
> (require 'ob-haskell)
> (require 'ob-latex)
> (require 'ob-sh)
> (require 'ob-asymptote)
> (require 'ob-R)
> (require 'ob-gnuplot)
>
> The following works fine:
>           #+tblname: example-table
>           | 1 |
>           | 2 |
>           | 3 |
>           | 4 |
>
>           #+source: table-length
>           #+begin_src emacs-lisp  :var table=example-table
>           (length table)
>           #+end_src
>
>           #+results: table-length
> 	  : 4
>
> But when I try the haskell equivalent:
>           #+source: table-length
>           #+begin_src haskell  :var table=example-table
>           length table
>           #+end_src
>
>
> I get:
> executing haskell source code block
> reference 'example-table' not found in this buffer
> org-babel-ref-resolve-reference: reference 'example-table' not found
> in this buffer
>
> If I try:
>           #+source: table-length
>           #+begin_src haskell
>           length [1,2,3]
>           #+end_src
>
>
> I get:
> executing haskell source code block
> org-babel-execute:haskell: Symbol's function definition is void: session
>

Thanks for bringing this up, it looks like ob-haskell has fallen victim
to bit-rot.  I've done a fairly thorough cleanup of the file (just
pushed up the commit).  Please give it a test run and let me know
if/where I missed issues.

>
>
> I also get a lot of warnings when I compile org-mode, see the attached
> buiild log.
>

Yes, the language-specific files have not been manicured for clean
byte-compilation.  This is certainly something that should happen, but
probably not in the near term.

Thanks -- Eric

>
>
> Thanks for your help,
>
> Chris Witte.
>
> On 23 June 2010 23:09, Eric Schulte <schulte.eric@gmail.com> wrote:
>> Hi,
>>
>> I've just merged the babel branch into the main branch of Org-mode.
>> This merge culminates much integration work by Dan Davison and Tom Dye,
>> as well as myself.
>>
>> Babel is now part of Org-mode.
>>
>> The biggest changes are:
>>
>> 1) Babel now has documentation!  It is part of Org-mode's documentation
>>
>>   see Chapter 14 _Working With Source Code_
>>
>>   also, the Babel keybindings are now listed in the refcard, and can be
>>   viewed from any Org-mode buffer by pressing C-c C-v h
>>
>> 2) Babel will now be loaded by default along with the rest of Org-mode.
>>   This means that *everyone* currently using babel will need to change
>>   their Emacs config and remove the (require 'org-babel-int) and/or
>>   (require 'org-babel) lines.
>>
>>   Support for evaluating emacs-lisp code blocks is loaded by default.
>>   All other languages will need to be required explicitly.  To conform
>>   to Emacs filename specifications all language require lines have been
>>   shortened from e.g.
>>
>>   (require 'org-babel-sh)
>>
>>   to
>>
>>   (require 'ob-sh)
>>
>> Thanks -- 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
>>
>
> _______________________________________________
> 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

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

[Rainer M Krug]

[-- Attachment #1.1: Type: text/plain, Size: 1730 bytes --]

On Mon, Jun 28, 2010 at 6:03 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> Hi Rainer,
>
> I'm happy this was useful
>
> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte <schulte.eric@gmail.com
> >wrote:
>
> [...]
> >> >
> >> > *** Start babel
> >> > #+begin_src emacs-lisp
> >> >   (org-babel-load-library-of-babel)
> >> > #+end_src
> >>
> >> the above becomes
> >>
> >> #+begin_src emacs-lisp
> >>  (org-babel-lob-ingest "~/path/to/org/contrib/babel/
> library-of-babel.org")
> >> #+end_src
> >>
> >
> > I don't seem to need this line anymore -  it is working without. Also, I
> > don't remember why I put it in...
> >
>
> The `org-babel-lob-ingest' function is used to load the source-code
> blocks defined in an Org-mode file into the global
> `org-babel-library-of-babel' variable.  The functions defined in this
> variable can be called from any Org-mode file.  This makes it possible
> to build a set of often-used generally applicable source-code blocks.
>
> The idea behind the library-of-babel.org file distributed with Org-mode
> is to share such functions throughout the entire Org-mode community.
>

Thanks - now I understand it,

Rainer


>
> Best -- Eric
>



-- 
NEW GERMAN FAX NUMBER!!!

Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Natural Sciences Building
Office Suite 2039
Stellenbosch University
Main Campus, Merriman Avenue
Stellenbosch
South Africa

Cell:           +27 - (0)83 9479 042
Fax:            +27 - (0)86 516 2782
Fax:            +49 - (0)321 2125 2244
email:          Rainer@krugs.de

Skype:          RMkrug
Google:         R.M.Krug@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 2824 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Matt Lundin]

Hi Eric,

Thanks again for all the work that you, Dan, and Tom have put into
org-babel. I'm glad to see it become part of org-mode!

"Eric Schulte" <schulte.eric@gmail.com> writes:

> 2) Babel will now be loaded by default along with the rest of Org-mode.
>    This means that *everyone* currently using babel will need to change
>    their Emacs config and remove the (require 'org-babel-int) and/or
>    (require 'org-babel) lines.

I would like to request that org-babel be made an optional module. I ask
this as someone who uses org-babel regularly. Here are my reasons:

  - Org-babel adds rather specific and complex functionality to org-mode
    that those who use it as a simple outliner and todo manager do not
    require. (In other words, an option to turn it off might be nice for
    those who are worried about "feature creep.")

  - Org-babel increases the risk of accidentally executing malicious or
    dangerous code when typing C-c C-c on a src block or exporting a
    file. Perhaps users should activate it only after they understand
    the risks.

    + For instance, I might write a blog post warning about the dangers
      of typing "rm -rf ~/". If I put this between #+begin_src sh
      and #+end_src and unthinkingly hit C-c C-c, I would be in trouble.
      I believe this is the reason for the variables
      org-confirm-shell-link-function and
      org-confirm-elisp-link-function.

    + This is admitted a bit far-fetched as an example, as it would
      require one to have loaded ob-sh.el. But since elisp execution is
      activated by default, there remain opportunities for unwittingly
      executing code that is meant for other purposes (e.g., warnings,
      examples, etc.).

>    Support for evaluating emacs-lisp code blocks is loaded by default.
>    All other languages will need to be required explicitly.  To conform
>    to Emacs filename specifications all language require lines have been
>    shortened from e.g.
>    
>    (require 'org-babel-sh)
>    
>    to
>    
>    (require 'ob-sh)

When I run make clean && make && make install I find that the language
directory is not installed. Does the langs directory require a manual
installation?

Also, with make install, the ob-* files are installed on the same level
as the org-files, yet lines 108-114 in org.el indicate that they should
be installed in a babel subdirectory.

Thanks!
Matt

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

[Nick Dokos]

Matt Lundin <mdl@imapmail.org> wrote:


> When I run make clean && make && make install I find that the language
> directory is not installed. Does the langs directory require a manual
> installation?
> 

It's part of the git repository, so it should be present after you do a
git pull.

> Also, with make install, the ob-* files are installed on the same level
> as the org-files, yet lines 108-114 in org.el indicate that they should
> be installed in a babel subdirectory.
> 

Not here: they end up in <org-mode>/lisp/babel.

Nick

versions:

Org-mode version 6.36trans (release_6.36.448.gb954)
GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2010-05-17

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

[Matt Lundin]

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> Matt Lundin <mdl@imapmail.org> wrote:
>
>
>> When I run make clean && make && make install I find that the language
>> directory is not installed. Does the langs directory require a manual
>> installation?
>> 
>
> It's part of the git repository, so it should be present after you do a
> git pull.

My apologies if my question wasn't clear. Yes, I can see the langs
directory in the org-mode repo. The problem, however, is that "make
install" does not copy the lang files to the target lispdir (in my case,
/usr/local/share/emacs/site-lisp). I'm not sure about the conventional
way to handle such installation in a Makefile, but it seems that the
babel/langs/* files have to added to LISPF.

>
>> Also, with make install, the ob-* files are installed on the same level
>> as the org-files, yet lines 108-114 in org.el indicate that they should
>> be installed in a babel subdirectory.
>> 
>
> Not here: they end up in <org-mode>/lisp/babel.

What does <org-mode> represent here? Are you invoking "make install" to
install to a target directory (lispdir) or are you simply leaving the
compiled lisp files in place in the local org-mode repository? 

This section of the lisp file flattens out the lisp/babel hierarchy in
the repo when copying to the target directory:

--8<---------------cut here---------------start------------->8---
install-lisp: $(LISPFILES) $(ELCFILES)
    if [ ! -d $(lispdir) ]; then $(MKDIR) $(lispdir); else true; fi ;
    $(CP) $(LISPFILES) $(lispdir)
    $(CP) $(ELCFILES)  $(lispdir)
--8<---------------cut here---------------end--------------->8---

Thanks,
Matt

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

[Matthew Lundin]

Matt Lundin <mdl@imapmail.org> writes:

> This section of the lisp file flattens out the lisp/babel hierarchy in
> the repo when copying to the target directory:

The above should read: "This section of the Makefile..."

>
> install-lisp: $(LISPFILES) $(ELCFILES)
>     if [ ! -d $(lispdir) ]; then $(MKDIR) $(lispdir); else true; fi ;
>     $(CP) $(LISPFILES) $(lispdir)
>     $(CP) $(ELCFILES)  $(lispdir)
>

- Matt

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

[Eric Schulte]

Hi Matt,

Thanks for raising the point about potentially dangerous code blocks.

Matt Lundin <mdl@imapmail.org> writes:

> Hi Eric,
>
> Thanks again for all the work that you, Dan, and Tom have put into
> org-babel. I'm glad to see it become part of org-mode!
>
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> 2) Babel will now be loaded by default along with the rest of Org-mode.
>>    This means that *everyone* currently using babel will need to change
>>    their Emacs config and remove the (require 'org-babel-int) and/or
>>    (require 'org-babel) lines.
>
> I would like to request that org-babel be made an optional module. I ask
> this as someone who uses org-babel regularly. Here are my reasons:
>
>   - Org-babel adds rather specific and complex functionality to org-mode
>     that those who use it as a simple outliner and todo manager do not
>     require. (In other words, an option to turn it off might be nice for
>     those who are worried about "feature creep.")
>

I'm less struck by this point, as there are many features of Org-mode
which I personally don't understand or use and I'm certainly some
features the existence of which I am completely unaware.  However as
long as Babel doesn't significantly affect load time, I'd rather it be
present in the background, to simplify it's use.

>
>   - Org-babel increases the risk of accidentally executing malicious or
>     dangerous code when typing C-c C-c on a src block or exporting a
>     file. Perhaps users should activate it only after they understand
>     the risks.
>
>     + For instance, I might write a blog post warning about the dangers
>       of typing "rm -rf ~/". If I put this between #+begin_src sh
>       and #+end_src and unthinkingly hit C-c C-c, I would be in trouble.
>       I believe this is the reason for the variables
>       org-confirm-shell-link-function and
>       org-confirm-elisp-link-function.
>

This to me is a much more motivating concern.  With arbitrary code
evaluation there is unlimited room for mayhem and destruction (both
malicious and accidental), although anyone who works with code in any
form is already exposed to such risks.

>
>     + This is admitted a bit far-fetched as an example, as it would
>       require one to have loaded ob-sh.el. But since elisp execution is
>       activated by default, there remain opportunities for unwittingly
>       executing code that is meant for other purposes (e.g., warnings,
>       examples, etc.).
>

No I don't think it's far fetched at all.  I think any of the three
following solutions (with a strong preference for the first) should
address this problem.

1) My preferred solution would be to keep things largely as they are,
   only w/o emacs-lisp activated by default.  That way there is no
   required configuration change for babel users (aside from having to
   add an 'ob-emacs-lisp require), and we address the issue of
   unintentional code execution -- anyone who has activated a language
   is presumably aware of what they are doing.
   
   Additionally this solution would retain some non-active Babel
   features like tangling.

2) We could add a new global environment variable along the lines of
   org-confirm-shell-link-function, say org-confirm-babel-execution or
   somesuch.  This would be easy to implement, and would retain tangle
   like functionality but doesn't seem as conceptually clean as the
   above solution.

3) We package babel as a module, which would need to be explicitly
   required to be used.

>
>>    Support for evaluating emacs-lisp code blocks is loaded by default.
>>    All other languages will need to be required explicitly.  To conform
>>    to Emacs filename specifications all language require lines have been
>>    shortened from e.g.
>>    
>>    (require 'org-babel-sh)
>>    
>>    to
>>    
>>    (require 'ob-sh)
>
> When I run make clean && make && make install I find that the language
> directory is not installed. Does the langs directory require a manual
> installation?
>

Thanks for catching this, I never run "make install" and it didn't occur
to me to think about the installed directory structure for languages.

Currently the language-specific files occupy an odd role.  They are not
compiled or loaded by default because many of them have exotic/complex
dependencies which most users will want to avoid -- e.g. slime.  For
this reason they must be explicitly required by users, and I think for
the moment at least would need to be manually installed for a global
instillation -- although I suppose we could update the Makefile to begin
copying the un-compiled language files into the global lisp tree during
instillation.

At the same time the language files *are* part of Babel and Org-mode for
things like FSF copyright attribution, so they live in the Org-mode lisp
tree.

>
> Also, with make install, the ob-* files are installed on the same
> level as the org-files, yet lines 108-114 in org.el indicate that they
> should be installed in a babel subdirectory.
>

Looks like it may be necessary to move ob-* files out of LISPF and into
their own new Makefile variable, so they can be handled separately and
placed into a babel sub-directory.

Hope this make sense, please let me know what you think.

Thanks -- Eric

>
> Thanks!
> Matt

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

[Nick Dokos]

Matt Lundin <mdl@imapmail.org> wrote:

> >
> >> When I run make clean && make && make install I find that the language
> >> directory is not installed. Does the langs directory require a manual
> >> installation?
> >> 
> >
> > It's part of the git repository, so it should be present after you do a
> > git pull.
> 
> My apologies if my question wasn't clear. Yes, I can see the langs
> directory in the org-mode repo. The problem, however, is that "make
> install" does not copy the lang files to the target lispdir (in my case,
> /usr/local/share/emacs/site-lisp). I'm not sure about the conventional
> way to handle such installation in a Makefile, but it seems that the
> babel/langs/* files have to added to LISPF.
> 
> >
> >> Also, with make install, the ob-* files are installed on the same level
> >> as the org-files, yet lines 108-114 in org.el indicate that they should
> >> be installed in a babel subdirectory.
> >> 
> >
> > Not here: they end up in <org-mode>/lisp/babel.
> 
> What does <org-mode> represent here? Are you invoking "make install" to
> install to a target directory (lispdir) or are you simply leaving the
> compiled lisp files in place in the local org-mode repository? 
> 
> This section of the lisp file flattens out the lisp/babel hierarchy in
> the repo when copying to the target directory:
> 
> install-lisp: $(LISPFILES) $(ELCFILES)
>     if [ ! -d $(lispdir) ]; then $(MKDIR) $(lispdir); else true; fi ;
>     $(CP) $(LISPFILES) $(lispdir)
>     $(CP) $(ELCFILES)  $(lispdir)
> 

Ah, sorry for being dense: I forgot that I don't install - I run out of
the git repository.  Forgive my parochial view: there are indeed
problems with the install target in the makefile.

Nick

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

[Eric Schulte]

Hi all,

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Matt,
>
> Thanks for raising the point about potentially dangerous code blocks.
>
> Matt Lundin <mdl@imapmail.org> writes:

[...]

>>
>> Also, with make install, the ob-* files are installed on the same
>> level as the org-files, yet lines 108-114 in org.el indicate that they
>> should be installed in a babel subdirectory.
>>
>
> Looks like it may be necessary to move ob-* files out of LISPF and into
> their own new Makefile variable, so they can be handled separately and
> placed into a babel sub-directory.
>

I *believe* I've successfully made this change to the Makefile.  It
looks like the babel files are now installed into their own "babel"
subdirectory of the global lisp directory.

I hardly believe this worked since it is the product of naive Makefile
pattern matching (which has never worked for me in the past), however it
appears to be compiling on my system.

If someone who actually uses "make install" on their system (or is
confident writing Makefiles) can confirm that this patch works then I'll
apply it.

Thanks -- Eric

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

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

with attachment ;)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-update-Makefile-for-correct-instillation-of-Babel-fi.patch --]
[-- Type: text/x-diff, Size: 6453 bytes --]

From 24f99a2ebd3de464fdb60902f003b828c2f71003 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Tue, 29 Jun 2010 15:53:15 -0700
Subject: [PATCH] update Makefile for correct instillation of Babel files

---
 Makefile |  157 ++++++++++++++++++++++++++++++++-----------------------------
 1 files changed, 82 insertions(+), 75 deletions(-)

diff --git a/Makefile b/Makefile
index c767cbd..6641395 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,8 @@ EMACS=emacs
 prefix=/usr/local
 
 # Where local lisp files go.
-lispdir = $(prefix)/share/emacs/site-lisp
+lispdir  = $(prefix)/share/emacs/site-lisp
+lispbdir = $(lispdir)/babel
 
 # Where info files go.
 infodir = $(prefix)/share/info
@@ -62,77 +63,79 @@ INSTALL_INFO=install-info
 ##----------------------------------------------------------------------
 
 # The following variables need to be defined by the maintainer
-LISPF      = 	org.el				\
-		org-agenda.el			\
-		org-ascii.el			\
-	     	org-attach.el			\
-	     	org-archive.el			\
-		org-bbdb.el			\
-		org-beamer.el			\
-		org-bibtex.el			\
-	     	org-capture.el			\
-	     	org-clock.el			\
-	     	org-colview.el			\
-	     	org-colview-xemacs.el		\
-	     	org-compat.el			\
-	     	org-crypt.el			\
-	     	org-ctags.el			\
-	     	org-datetree.el			\
-	     	org-docview.el			\
-	     	org-entities.el			\
-		org-exp.el			\
-		org-exp-blocks.el		\
-		org-docbook.el			\
-		org-faces.el			\
-		org-feed.el			\
-		org-footnote.el			\
-		org-freemind.el			\
-		org-gnus.el			\
-		org-habit.el			\
-		org-html.el			\
-		org-icalendar.el		\
-		org-id.el			\
-		org-indent.el			\
-		org-info.el			\
-		org-inlinetask.el		\
-		org-jsinfo.el			\
-		org-irc.el			\
-		org-latex.el			\
-		org-list.el			\
-		org-mac-message.el		\
-	     	org-macs.el			\
-		org-mew.el              	\
-		org-mhe.el			\
-		org-mks.el			\
-		org-mobile.el			\
-		org-mouse.el			\
-		org-publish.el			\
-		org-plot.el			\
-		org-protocol.el			\
-		org-remember.el			\
-		org-rmail.el			\
-		org-src.el			\
-		org-table.el			\
-		org-taskjuggler.el		\
-		org-timer.el			\
-		org-vm.el			\
-		org-w3m.el              	\
-		org-wl.el			\
-		org-xoxo.el			\
-		babel/ob.el			\
-		babel/ob-table.el		\
-		babel/ob-lob.el			\
-		babel/ob-ref.el			\
-		babel/ob-exp.el			\
-		babel/ob-tangle.el		\
-		babel/ob-comint.el		\
-		babel/ob-keys.el		\
-		babel/langs/ob-emacs-lisp.el
+LISPF      = 	org.el			\
+		org-agenda.el		\
+		org-ascii.el		\
+	     	org-attach.el		\
+	     	org-archive.el		\
+		org-bbdb.el		\
+		org-beamer.el		\
+		org-bibtex.el		\
+	     	org-capture.el		\
+	     	org-clock.el		\
+	     	org-colview.el		\
+	     	org-colview-xemacs.el	\
+	     	org-compat.el		\
+	     	org-crypt.el		\
+	     	org-ctags.el		\
+	     	org-datetree.el		\
+	     	org-docview.el		\
+	     	org-entities.el		\
+		org-exp.el		\
+		org-exp-blocks.el	\
+		org-docbook.el		\
+		org-faces.el		\
+		org-feed.el		\
+		org-footnote.el		\
+		org-freemind.el		\
+		org-gnus.el		\
+		org-habit.el		\
+		org-html.el		\
+		org-icalendar.el	\
+		org-id.el		\
+		org-indent.el		\
+		org-info.el		\
+		org-inlinetask.el	\
+		org-jsinfo.el		\
+		org-irc.el		\
+		org-latex.el		\
+		org-list.el		\
+		org-mac-message.el	\
+	     	org-macs.el		\
+		org-mew.el              \
+		org-mhe.el		\
+		org-mks.el		\
+		org-mobile.el		\
+		org-mouse.el		\
+		org-publish.el		\
+		org-plot.el		\
+		org-protocol.el		\
+		org-remember.el		\
+		org-rmail.el		\
+		org-src.el		\
+		org-table.el		\
+		org-taskjuggler.el	\
+		org-timer.el		\
+		org-vm.el		\
+		org-w3m.el              \
+		org-wl.el		\
+		org-xoxo.el
+
+LISPBF     = 	ob.el			\
+		ob-table.el		\
+		ob-lob.el		\
+		ob-ref.el		\
+		ob-exp.el		\
+		ob-tangle.el		\
+		ob-comint.el		\
+		ob-keys.el
 
 LISPFILES0 = $(LISPF:%=lisp/%)
 LISPFILES  = $(LISPFILES0) lisp/org-install.el
+LISPBFILES = $(LISPBF:%=lisp/babel/%)
 ELCFILES0  = $(LISPFILES0:.el=.elc)
 ELCFILES   = $(LISPFILES:.el=.elc)
+ELCBFILES  = $(LISPBFILES:.el=.elc)
 DOCFILES   = doc/org.texi doc/org.pdf doc/org doc/dir \
              doc/pdflayout.sty doc/.nosearch \
              doc/orgguide.texi doc/orgguide.pdf
@@ -148,9 +151,9 @@ SHELL = /bin/sh
 DISTFILES_extra=  Makefile ChangeLog request-assign-future.txt contrib
 DISTFILES_xemacs=  xemacs/noutline.el xemacs/ps-print-invisible.el xemacs/README
 
-default: $(ELCFILES)
+default: $(ELCFILES) $(ELCBFILES)
 
-all:	$(ELCFILES) $(INFOFILES)
+all:	$(ELCFILES) $(ELCBFILES) $(INFOFILES)
 
 up2:	update
 	sudo ${MAKE} install
@@ -160,7 +163,7 @@ update:
 	${MAKE} clean
 	${MAKE} all
 
-compile: $(ELCFILES0)
+compile: $(ELCFILES0) $(ELCBFILES)
 
 install: install-lisp
 
@@ -172,10 +175,13 @@ p:
 g:
 	${MAKE} pdf && open doc/orgguide.pdf
 
-install-lisp: $(LISPFILES) $(ELCFILES)
+install-lisp: $(LISPFILES) $(LISPBFILES) $(ELCFILES)
 	if [ ! -d $(lispdir) ]; then $(MKDIR) $(lispdir); else true; fi ;
-	$(CP) $(LISPFILES) $(lispdir)
-	$(CP) $(ELCFILES)  $(lispdir)
+	if [ ! -d $(lispbdir) ]; then $(MKDIR) $(lispbdir); else true; fi ;
+	$(CP) $(LISPFILES)  $(lispdir)
+	$(CP) $(ELCFILES)   $(lispdir)
+	$(CP) $(LISPBFILES) $(lispbdir)
+	$(CP) $(ELCBFILES)  $(lispbdir)
 
 install-info: $(INFOFILES)
 	if [ ! -d $(infodir) ]; then $(MKDIR) $(infodir); else true; fi ;
@@ -191,11 +197,11 @@ install-noutline: xemacs/noutline.elc
 
 autoloads: lisp/org-install.el
 
-lisp/org-install.el: $(LISPFILES0) Makefile
+lisp/org-install.el: $(LISPFILES0) $(LISPBFILES) Makefile
 	$(BATCH) --eval "(require 'autoload)" \
 		--eval '(find-file "org-install.el")'  \
 		--eval '(erase-buffer)' \
-		--eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name x))) (quote ($(LISPFILES0))))' \
+		--eval '(mapc (lambda (x) (generate-file-autoloads (symbol-name x))) (quote ($(LISPFILES0) $(LISPBFILES))))' \
 		--eval "(insert \"(add-to-list 'load-path (expand-file-name \\\"babel\\\" (file-name-directory (or (buffer-file-name) load-file-name))))\")" \
 		--eval "(insert \"\n(add-to-list 'load-path (expand-file-name \\\"langs\\\" (expand-file-name \\\"babel\\\" (file-name-directory (or (buffer-file-name) load-file-name)))))\")\n" \
 		--eval '(insert "\n(provide (quote org-install))\n")' \
@@ -268,6 +274,7 @@ distfile:
 	$(MKDIR) org-$(TAG)/doc
 	$(MKDIR) org-$(TAG)/lisp
 	cp -r $(LISPFILES) org-$(TAG)/lisp
+	cp -r $(LISPBFILES) org-$(TAG)/lisp/babel
 	cp -r $(DOCFILES) $(CARDFILES) org-$(TAG)/doc
 	cp -r $(DISTFILES_extra) org-$(TAG)/
 	cp -r README_DIST org-$(TAG)/README
-- 
1.7.0.4


[-- Attachment #3: Type: text/plain, Size: 1208 bytes --]


"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi all,
>
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Hi Matt,
>>
>> Thanks for raising the point about potentially dangerous code blocks.
>>
>> Matt Lundin <mdl@imapmail.org> writes:
>
> [...]
>
>>>
>>> Also, with make install, the ob-* files are installed on the same
>>> level as the org-files, yet lines 108-114 in org.el indicate that they
>>> should be installed in a babel subdirectory.
>>>
>>
>> Looks like it may be necessary to move ob-* files out of LISPF and into
>> their own new Makefile variable, so they can be handled separately and
>> placed into a babel sub-directory.
>>
>
> I *believe* I've successfully made this change to the Makefile.  It
> looks like the babel files are now installed into their own "babel"
> subdirectory of the global lisp directory.
>
> I hardly believe this worked since it is the product of naive Makefile
> pattern matching (which has never worked for me in the past), however it
> appears to be compiling on my system.
>
> If someone who actually uses "make install" on their system (or is
> confident writing Makefiles) can confirm that this patch works then I'll
> apply it.
>
> Thanks -- Eric

[-- Attachment #4: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Nick Dokos]

Eric Schulte <schulte.eric@gmail.com> wrote:

> --=-=-=
> 
> with attachment ;)
> 
> >
> > I hardly believe this worked since it is the product of naive Makefile
> > pattern matching (which has never worked for me in the past), however it
> > appears to be compiling on my system.
> >
> > If someone who actually uses "make install" on their system (or is
> > confident writing Makefiles) can confirm that this patch works then I'll
> > apply it.
> >
> > Thanks -- Eric
> 

I took a quick look and I couldn't see where the babel/langs subdirectory
is copied over to the install directory - did I miss it?

Nick

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

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Nick Dokos <nicholas.dokos@hp.com> writes:

> Eric Schulte <schulte.eric@gmail.com> wrote:
>
>> --=-=-=
>> 
>> with attachment ;)
>> 
>> >
>> > I hardly believe this worked since it is the product of naive Makefile
>> > pattern matching (which has never worked for me in the past), however it
>> > appears to be compiling on my system.
>> >
>> > If someone who actually uses "make install" on their system (or is
>> > confident writing Makefiles) can confirm that this patch works then I'll
>> > apply it.
>> >
>> > Thanks -- Eric
>> 
>
> I took a quick look and I couldn't see where the babel/langs subdirectory
> is copied over to the install directory - did I miss it?
>

Ah, thanks, an undated patch is attached.  Best -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: babel-make-install.patch --]
[-- Type: text/x-diff, Size: 0 bytes --]



[-- Attachment #3: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 22 bytes --]

non-empty attachment


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: babel-make-install.patch --]
[-- Type: text/x-diff, Size: 6656 bytes --]

diff --git a/Makefile b/Makefile
index d4da79d..f6538ce 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,9 @@ EMACS=emacs
 prefix=/usr/local
 
 # Where local lisp files go.
-lispdir = $(prefix)/share/emacs/site-lisp
+lispdir   = $(prefix)/share/emacs/site-lisp
+lispbdir  = $(lispdir)/babel
+lispbldir = $(lispbdir)/langs
 
 # Where info files go.
 infodir = $(prefix)/share/info
@@ -62,83 +64,109 @@ INSTALL_INFO=install-info
 ##----------------------------------------------------------------------
 
 # The following variables need to be defined by the maintainer
-LISPF      = 	org.el				\
-		org-agenda.el			\
-		org-ascii.el			\
-	     	org-attach.el			\
-	     	org-archive.el			\
-		org-bbdb.el			\
-		org-beamer.el			\
-		org-bibtex.el			\
-	     	org-capture.el			\
-	     	org-clock.el			\
-	     	org-colview.el			\
-	     	org-colview-xemacs.el		\
-	     	org-compat.el			\
-	     	org-crypt.el			\
-	     	org-ctags.el			\
-	     	org-datetree.el			\
-	     	org-docview.el			\
-	     	org-entities.el			\
-		org-exp.el			\
-		org-exp-blocks.el		\
-		org-docbook.el			\
-		org-faces.el			\
-		org-feed.el			\
-		org-footnote.el			\
-		org-freemind.el			\
-		org-gnus.el			\
-		org-habit.el			\
-		org-html.el			\
-		org-icalendar.el		\
-		org-id.el			\
-		org-indent.el			\
-		org-info.el			\
-		org-inlinetask.el		\
-		org-jsinfo.el			\
-		org-irc.el			\
-		org-latex.el			\
-		org-list.el			\
-		org-mac-message.el		\
-	     	org-macs.el			\
-		org-mew.el              	\
-		org-mhe.el			\
-		org-mks.el			\
-		org-mobile.el			\
-		org-mouse.el			\
-		org-publish.el			\
-		org-plot.el			\
-		org-protocol.el			\
-		org-remember.el			\
-		org-rmail.el			\
-		org-src.el			\
-		org-table.el			\
-		org-taskjuggler.el		\
-		org-timer.el			\
-		org-vm.el			\
-		org-w3m.el              	\
-		org-wl.el			\
-		org-xoxo.el			\
-		babel/ob.el			\
-		babel/ob-table.el		\
-		babel/ob-lob.el			\
-		babel/ob-ref.el			\
-		babel/ob-exp.el			\
-		babel/ob-tangle.el		\
-		babel/ob-comint.el		\
-		babel/ob-keys.el		\
-		babel/langs/ob-emacs-lisp.el
-
-LISPFILES0 = $(LISPF:%=lisp/%)
-LISPFILES  = $(LISPFILES0) lisp/org-install.el
-ELCFILES0  = $(LISPFILES0:.el=.elc)
-ELCFILES   = $(LISPFILES:.el=.elc)
-DOCFILES   = doc/org.texi doc/org.pdf doc/org doc/dir \
-             doc/pdflayout.sty doc/.nosearch \
-             doc/orgguide.texi doc/orgguide.pdf
-CARDFILES  = doc/orgcard.tex doc/orgcard.pdf doc/orgcard_letter.pdf
-TEXIFILES  = doc/org.texi
-INFOFILES  = doc/org
+LISPF      = 	org.el			\
+		org-agenda.el		\
+		org-ascii.el		\
+	     	org-attach.el		\
+	     	org-archive.el		\
+		org-bbdb.el		\
+		org-beamer.el		\
+		org-bibtex.el		\
+	     	org-capture.el		\
+	     	org-clock.el		\
+	     	org-colview.el		\
+	     	org-colview-xemacs.el	\
+	     	org-compat.el		\
+	     	org-crypt.el		\
+	     	org-ctags.el		\
+	     	org-datetree.el		\
+	     	org-docview.el		\
+	     	org-entities.el		\
+		org-exp.el		\
+		org-exp-blocks.el	\
+		org-docbook.el		\
+		org-faces.el		\
+		org-feed.el		\
+		org-footnote.el		\
+		org-freemind.el		\
+		org-gnus.el		\
+		org-habit.el		\
+		org-html.el		\
+		org-icalendar.el	\
+		org-id.el		\
+		org-indent.el		\
+		org-info.el		\
+		org-inlinetask.el	\
+		org-jsinfo.el		\
+		org-irc.el		\
+		org-latex.el		\
+		org-list.el		\
+		org-mac-message.el	\
+	     	org-macs.el		\
+		org-mew.el              \
+		org-mhe.el		\
+		org-mks.el		\
+		org-mobile.el		\
+		org-mouse.el		\
+		org-publish.el		\
+		org-plot.el		\
+		org-protocol.el		\
+		org-remember.el		\
+		org-rmail.el		\
+		org-src.el		\
+		org-table.el		\
+		org-taskjuggler.el	\
+		org-timer.el		\
+		org-vm.el		\
+		org-w3m.el              \
+		org-wl.el		\
+		org-xoxo.el
+
+LISPBF     = 	ob.el			\
+		ob-table.el		\
+		ob-lob.el		\
+		ob-ref.el		\
+		ob-exp.el		\
+		ob-tangle.el		\
+		ob-comint.el		\
+		ob-keys.el
+
+LISPBLF   =	ob-C.el			\
+		ob-ditaa.el		\
+		ob-haskell.el		\
+		ob-perl.el		\
+		ob-sh.el		\
+		ob-R.el			\
+		ob-dot.el		\
+		ob-latex.el		\
+		ob-python.el		\
+		ob-sql.el		\
+		ob-asymptote.el		\
+		ob-emacs-lisp.el	\
+		ob-matlab.el		\
+		ob-ruby.el		\
+		ob-sqlite.el		\
+		ob-clojure.el		\
+		ob-ocaml.el		\
+		ob-sass.el		\
+		ob-css.el		\
+		ob-gnuplot.el		\
+		ob-octave.el		\
+		ob-screen.el
+
+LISPFILES0  = $(LISPF:%=lisp/%)
+LISPFILES   = $(LISPFILES0) lisp/org-install.el
+LISPBFILES  = $(LISPBF:%=lisp/babel/%)
+LISPBLFILES = $(LISPBLF:%=lisp/babel/langs/%)
+ELCFILES0   = $(LISPFILES0:.el=.elc)
+ELCFILES    = $(LISPFILES:.el=.elc)
+ELCBFILES   = $(LISPBFILES:.el=.elc)
+DOCFILES    = doc/org.texi doc/org.pdf doc/org doc/dir \
+              doc/pdflayout.sty doc/.nosearch \
+              doc/orgguide.texi doc/orgguide.pdf
+CARDFILES   = doc/orgcard.tex doc/orgcard.pdf doc/orgcard_letter.pdf
+TEXIFILES   = doc/org.texi
+INFOFILES   = doc/org
 
 
 .SUFFIXES: .el .elc .texi
@@ -148,9 +176,9 @@ SHELL = /bin/sh
 DISTFILES_extra=  Makefile ChangeLog request-assign-future.txt contrib
 DISTFILES_xemacs=  xemacs/noutline.el xemacs/ps-print-invisible.el xemacs/README
 
-default: $(ELCFILES)
+default: $(ELCFILES) $(ELCBFILES)
 
-all:	$(ELCFILES) $(INFOFILES)
+all:	$(ELCFILES) $(ELCBFILES) $(INFOFILES)
 
 up2:	update
 	sudo ${MAKE} install
@@ -160,7 +188,7 @@ update:
 	${MAKE} clean
 	${MAKE} all
 
-compile: $(ELCFILES0)
+compile: $(ELCFILES0) $(ELCBFILES)
 
 install: install-lisp
 
@@ -172,10 +200,15 @@ p:
 g:
 	${MAKE} pdf && open doc/orgguide.pdf
 
-install-lisp: $(LISPFILES) $(ELCFILES)
+install-lisp: $(LISPFILES) $(LISPBFILES) $(ELCFILES)
 	if [ ! -d $(lispdir) ]; then $(MKDIR) $(lispdir); else true; fi ;
-	$(CP) $(LISPFILES) $(lispdir)
-	$(CP) $(ELCFILES)  $(lispdir)
+	if [ ! -d $(lispbdir) ]; then $(MKDIR) $(lispbdir); else true; fi ;
+	if [ ! -d $(lispbldir) ]; then $(MKDIR) $(lispbldir); else true; fi ;
+	$(CP) $(LISPFILES)  $(lispdir)
+	$(CP) $(ELCFILES)   $(lispdir)
+	$(CP) $(LISPBFILES) $(lispbdir)
+	$(CP) $(ELCBFILES)  $(lispbdir)
+	$(CP) $(LISPBLFILES) $(lispbldir)
 
 install-info: $(INFOFILES)
 	if [ ! -d $(infodir) ]; then $(MKDIR) $(infodir); else true; fi ;
@@ -191,7 +224,7 @@ install-noutline: xemacs/noutline.elc
 
 autoloads: lisp/org-install.el
 
-lisp/org-install.el: $(LISPFILES0) Makefile
+lisp/org-install.el: $(LISPFILES0) $(LISPBFILES) Makefile
 	$(BATCH) --eval "(require 'autoload)" \
 		--eval '(find-file "org-install.el")'  \
 		--eval '(erase-buffer)' \
@@ -268,6 +301,7 @@ distfile:
 	$(MKDIR) org-$(TAG)/doc
 	$(MKDIR) org-$(TAG)/lisp
 	cp -r $(LISPFILES) org-$(TAG)/lisp
+	cp -r $(LISPBFILES) org-$(TAG)/lisp/babel
 	cp -r $(DOCFILES) $(CARDFILES) org-$(TAG)/doc
 	cp -r $(DISTFILES_extra) org-$(TAG)/
 	cp -r README_DIST org-$(TAG)/README

[-- Attachment #3: Type: text/plain, Size: 808 bytes --]


"Eric Schulte" <schulte.eric@gmail.com> writes:

> Nick Dokos <nicholas.dokos@hp.com> writes:
>
>> Eric Schulte <schulte.eric@gmail.com> wrote:
>>
>>> --=-=-=
>>> 
>>> with attachment ;)
>>> 
>>> >
>>> > I hardly believe this worked since it is the product of naive Makefile
>>> > pattern matching (which has never worked for me in the past), however it
>>> > appears to be compiling on my system.
>>> >
>>> > If someone who actually uses "make install" on their system (or is
>>> > confident writing Makefiles) can confirm that this patch works then I'll
>>> > apply it.
>>> >
>>> > Thanks -- Eric
>>> 
>>
>> I took a quick look and I couldn't see where the babel/langs subdirectory
>> is copied over to the install directory - did I miss it?
>>
>
> Ah, thanks, an undated patch is attached.  Best -- Eric

[-- Attachment #4: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Carsten Dominik]

Hi Matt, hi Eric,

Matt, thanks a lot for bringing this up.  This is indeed a very
important and serious issue.  We need to address it.  We need to
step back and reconsider this carefully.

Don't get me wrong, I absolutely think that Org Babel should give
you enough rope to hang yourself.  But we have to make sure that
this will not happen to a happy and unsuspecting Org mode, or even
an unsuspecting Emacs user who by chance opens a file with  
extension .org.

I remember very well when  first realized that shell links could
really affect you badly.  It scared me.

You main proposal was to make Org Babel an optional module.
This will not solve the problem fully, I think, because we also
don't want that people who turn it on automatically commit
to potentially dangerous operations.  There is a lot of good stuff
in Babel which has nothing to do with code evaluation.

Here is what I propose (several items are similar to what Eric proposes)

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.

2. As Eric proposes, a variable similar to org-confirm-shell-link- 
function
    This should by default query for confirmation on any org-babel
    code execution, and can be configured to shut up by people who know
    what they are doing.

3. Not loading emacs lisp evaluation by default.

4. A new key in the babel keymap for org-babel-execute-code-block,
    for example `C-c C-v e'.  This should be documented as the default
    key for this operation.

5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
    should be optional.

6. A section in the manual on code execution and associated security
    risks in Org mode.  This is not only about babel, but also about
    org-eval, org-eval-light, shell links and elisp links.  I have meant
    to write this section for a long time and would be willing to
    draft it. We could then refer to this section from a couple of
    places in the docs, without cluttering the docs with disclaimers.

The reason for 4 and 5 is that I believe Org-mode users are trained
to blindly press `C-c C-c' whenever they want to update something at
point.  Matt's example of a blog post about `rm -rf' is a very
realistic example for bad code being evaluated by mistake, not even
due to malicious cations.  I belive that a special key for this
action would gove a good measure of protection.

This is what I think - please let me know if you think I am overdoing  
it.

- Carsten


On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:

> Hi Eric,
>
> Thanks again for all the work that you, Dan, and Tom have put into
> org-babel. I'm glad to see it become part of org-mode!
>
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> 2) Babel will now be loaded by default along with the rest of Org- 
>> mode.
>>   This means that *everyone* currently using babel will need to  
>> change
>>   their Emacs config and remove the (require 'org-babel-int) and/or
>>   (require 'org-babel) lines.
>
> I would like to request that org-babel be made an optional module. I  
> ask
> this as someone who uses org-babel regularly. Here are my reasons:
>
>  - Org-babel adds rather specific and complex functionality to org- 
> mode
>    that those who use it as a simple outliner and todo manager do not
>    require. (In other words, an option to turn it off might be nice  
> for
>    those who are worried about "feature creep.")
>
>  - Org-babel increases the risk of accidentally executing malicious or
>    dangerous code when typing C-c C-c on a src block or exporting a
>    file. Perhaps users should activate it only after they understand
>    the risks.
>
>    + For instance, I might write a blog post warning about the dangers
>      of typing "rm -rf ~/". If I put this between #+begin_src sh
>      and #+end_src and unthinkingly hit C-c C-c, I would be in  
> trouble.
>      I believe this is the reason for the variables
>      org-confirm-shell-link-function and
>      org-confirm-elisp-link-function.
>
>    + This is admitted a bit far-fetched as an example, as it would
>      require one to have loaded ob-sh.el. But since elisp execution is
>      activated by default, there remain opportunities for unwittingly
>      executing code that is meant for other purposes (e.g., warnings,
>      examples, etc.).
>
>>   Support for evaluating emacs-lisp code blocks is loaded by default.
>>   All other languages will need to be required explicitly.  To  
>> conform
>>   to Emacs filename specifications all language require lines have  
>> been
>>   shortened from e.g.
>>
>>   (require 'org-babel-sh)
>>
>>   to
>>
>>   (require 'ob-sh)
>
> When I run make clean && make && make install I find that the language
> directory is not installed. Does the langs directory require a manual
> installation?
>
> Also, with make install, the ob-* files are installed on the same  
> level
> as the org-files, yet lines 108-114 in org.el indicate that they  
> should
> be installed in a babel subdirectory.
>
> Thanks!
> Matt
>
> _______________________________________________
> 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

- Carsten

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

[Scot Becker]

[-- Attachment #1.1: Type: text/plain, Size: 1594 bytes --]

On Tue, Jun 29, 2010 at 11:03 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> >   - Org-babel adds rather specific and complex functionality to org-mode
> >     that those who use it as a simple outliner and todo manager do not
> >     require. (In other words, an option to turn it off might be nice for
> >     those who are worried about "feature creep.")
> >
>
> I'm less struck by this point, as there are many features of Org-mode
> which I personally don't understand or use and I'm certainly some
> features the existence of which I am completely unaware.  However as
> long as Babel doesn't significantly affect load time, I'd rather it be
> present in the background, to simplify it's use.
>

And there's a significant advantage to having it included and 'on':
ubiquity.  An  org user doesn't have to have set anything up to load up
Eric's babel-ized version of the emacs starter kit and start playing with it
in babel.  [http://github.com/eschulte/emacs-starter-kit]

It's the same advantage that org-mode gains by being part of Emacs.  We can
say:  "Want to try org-mode?  just do 'M-x org-mode'  Now make some
headlines with CTRL-RET and...."  Org babel is good, useful and stable
enough that it deserves the same boost.

Having said that, I'm all for Carsten's new code execution key binding.  Org
advertises C-c C-c as a friendly key which mostly 'does the right thing' on
the current block.  I could imagine that unwary newish users might not
realize that in this case 'the right thing' is to execute that code.
Paranoia does seem a good default practice in this case.

Scot

[-- Attachment #1.2: Type: text/html, Size: 2192 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Matthew Lundin]

Hi Eric,

Thanks so much for taking these observations into account.

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Thanks for raising the point about potentially dangerous code blocks.
>
> Matt Lundin <mdl@imapmail.org> writes:
>
>> Hi Eric,
>>
>> Thanks again for all the work that you, Dan, and Tom have put into
>> org-babel. I'm glad to see it become part of org-mode!
>>
>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>
>>> 2) Babel will now be loaded by default along with the rest of Org-mode.
>>>    This means that *everyone* currently using babel will need to change
>>>    their Emacs config and remove the (require 'org-babel-int) and/or
>>>    (require 'org-babel) lines.
>>
>> I would like to request that org-babel be made an optional module. I ask
>> this as someone who uses org-babel regularly. Here are my reasons:
>>
>>   - Org-babel adds rather specific and complex functionality to org-mode
>>     that those who use it as a simple outliner and todo manager do not
>>     require. (In other words, an option to turn it off might be nice for
>>     those who are worried about "feature creep.")
>
> I'm less struck by this point, as there are many features of Org-mode
> which I personally don't understand or use and I'm certainly some
> features the existence of which I am completely unaware.  However as
> long as Babel doesn't significantly affect load time, I'd rather it be
> present in the background, to simplify it's use.

Yes, I can certainly understand this. My own preference is for
modularity and minimalism---i.e., if possible, give users the option of
*not* loading or requiring a package. For example, I appreciate that
org-habit is a module --- one doesn't have to load it if one doesn't
want to. But org-habit is perhaps more clearly an "add-on" than is
org-babel. Having used the latter only for perl, python, and shell code
evaluation, I imagine I underestimate the enhancements it makes to the
core functionality of org source blocks. :)

>>   - Org-babel increases the risk of accidentally executing malicious or
>>     dangerous code when typing C-c C-c on a src block or exporting a
>>     file. Perhaps users should activate it only after they understand
>>     the risks.
>>
>>     + For instance, I might write a blog post warning about the dangers
>>       of typing "rm -rf ~/". If I put this between #+begin_src sh
>>       and #+end_src and unthinkingly hit C-c C-c, I would be in trouble.
>>       I believe this is the reason for the variables
>>       org-confirm-shell-link-function and
>>       org-confirm-elisp-link-function.
>>
>
> This to me is a much more motivating concern.  With arbitrary code
> evaluation there is unlimited room for mayhem and destruction (both
> malicious and accidental), although anyone who works with code in any
> form is already exposed to such risks.
>

Yes, this is my primary concern.

>>
>>     + This is admitted a bit far-fetched as an example, as it would
>>       require one to have loaded ob-sh.el. But since elisp execution is
>>       activated by default, there remain opportunities for unwittingly
>>       executing code that is meant for other purposes (e.g., warnings,
>>       examples, etc.).
>>
>
> No I don't think it's far fetched at all.  I think any of the three
> following solutions (with a strong preference for the first) should
> address this problem.
>
> 1) My preferred solution would be to keep things largely as they are,
>    only w/o emacs-lisp activated by default.  That way there is no
>    required configuration change for babel users (aside from having to
>    add an 'ob-emacs-lisp require), and we address the issue of
>    unintentional code execution -- anyone who has activated a language
>    is presumably aware of what they are doing.
>    
>    Additionally this solution would retain some non-active Babel
>    features like tangling.
>
> 2) We could add a new global environment variable along the lines of
>    org-confirm-shell-link-function, say org-confirm-babel-execution or
>    somesuch.  This would be easy to implement, and would retain tangle
>    like functionality but doesn't seem as conceptually clean as the
>    above solution.

Perhaps some combination of 1 and 2?

Best,
Matt

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

[Matthew Lundin]

Hi Carsten,

Thanks so much both for thinking this through. And thanks again, Eric,
for your work in integrating org-babel into org-mode---including taking
into account a humble user's concerns! :)

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Here is what I propose (several items are similar to what Eric proposes)
>
> 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.

I think the default should be t, but I also like giving users the option
of not loading org-babel.

> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
> function
>    This should by default query for confirmation on any org-babel
>    code execution, and can be configured to shut up by people who know
>    what they are doing.
>
> 3. Not loading emacs lisp evaluation by default.
>
> 4. A new key in the babel keymap for org-babel-execute-code-block,
>    for example `C-c C-v e'.  This should be documented as the default
>    key for this operation.
>
> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>    should be optional.
>
> 6. A section in the manual on code execution and associated security
>    risks in Org mode.  This is not only about babel, but also about
>    org-eval, org-eval-light, shell links and elisp links.  I have meant
>    to write this section for a long time and would be willing to
>    draft it. We could then refer to this section from a couple of
>    places in the docs, without cluttering the docs with disclaimers.

With safeguards with 2, 4, 5, and 6, would it be safe to skip #3 and
load emacs-lisp evaluation by default? The primary risk right now is
that C-c C-c is so easy to press. But if we change the keybinding and
add a default warning, I believe the emacs-lisp evaluation would not
pose undue dangers. After all, emacs already makes it easy to evaluate
emacs-lisp code. IMO, other languages are a bit more dangerous, since
they are "out of context" in an org-mode document---i.e., one is not
necessarily as cautious about the pitfalls of executing shell commands,
perl code, etc. as one is when using the command line or executing a
script.

Best,
Matt

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

[Carsten Dominik]

On Jun 30, 2010, at 2:53 PM, Matthew Lundin wrote:

> Hi Carsten,
>
> Thanks so much both for thinking this through. And thanks again, Eric,
> for your work in integrating org-babel into org-mode---including  
> taking
> into account a humble user's concerns! :)
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Here is what I propose (several items are similar to what Eric  
>> proposes)
>>
>> 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.
>
> I think the default should be t, but I also like giving users the  
> option
> of not loading org-babel.
>
>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>> function
>>   This should by default query for confirmation on any org-babel
>>   code execution, and can be configured to shut up by people who know
>>   what they are doing.
>>
>> 3. Not loading emacs lisp evaluation by default.
>>
>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>   for example `C-c C-v e'.  This should be documented as the default
>>   key for this operation.
>>
>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>   should be optional.
>>
>> 6. A section in the manual on code execution and associated security
>>   risks in Org mode.  This is not only about babel, but also about
>>   org-eval, org-eval-light, shell links and elisp links.  I have  
>> meant
>>   to write this section for a long time and would be willing to
>>   draft it. We could then refer to this section from a couple of
>>   places in the docs, without cluttering the docs with disclaimers.
>
> With safeguards with 2, 4, 5, and 6, would it be safe to skip #3 and
> load emacs-lisp evaluation by default? The primary risk right now is
> that C-c C-c is so easy to press. But if we change the keybinding and
> add a default warning, I believe the emacs-lisp evaluation would not
> pose undue dangers.

I agree.


> After all, emacs already makes it easy to evaluate
> emacs-lisp code. IMO, other languages are a bit more dangerous, since
> they are "out of context" in an org-mode document---i.e., one is not
> necessarily as cautious about the pitfalls of executing shell  
> commands,
> perl code, etc. as one is when using the command line or executing a
> script.

Yes.  Emacs Lisp is of course just as dangerous as the shell or
anything else when it comes to malicious intent, but for running
code by mistake it is much less dangerous than the shell,
because usually elisp code deals with stuff inside Emacs
and not so much on the system.

- Carsten

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

[Eric Schulte]

Hi Carsten, Matt, Scott,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi Matt, hi Eric,
>
> Matt, thanks a lot for bringing this up.  This is indeed a very
> important and serious issue.  We need to address it.  We need to
> step back and reconsider this carefully.
>
> Don't get me wrong, I absolutely think that Org Babel should give
> you enough rope to hang yourself.  But we have to make sure that
> this will not happen to a happy and unsuspecting Org mode, or even
> an unsuspecting Emacs user who by chance opens a file with extension
> .org.
>
> I remember very well when  first realized that shell links could
> really affect you badly.  It scared me.
>
> You main proposal was to make Org Babel an optional module.
> This will not solve the problem fully, I think, because we also
> don't want that people who turn it on automatically commit
> to potentially dangerous operations.  There is a lot of good stuff
> in Babel which has nothing to do with code evaluation.
>
> Here is what I propose (several items are similar to what Eric proposes)
>
> 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.

>
> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>    function
>    This should by default query for confirmation on any org-babel
>    code execution, and can be configured to shut up by people who know
>    what they are doing.
>

Sounds good, I think this is a reasonable safety measure.

>
> 3. Not loading emacs lisp evaluation by default.
>

I would push back on this point.  Largely because we have now crossed
the like to where it is impossible to play with a code block w/o first
dropping down to your configuration files, and evaluating require
statements.

>
> 4. A new key in the babel keymap for org-babel-execute-code-block,
>    for example `C-c C-v e'.  This should be documented as the default
>    key for this operation.
>

Hmm, I'm less enthusiastic about this point and point 5.  I really like
how 'C-c C-c' naturally does whatever-I-want given the context in which
it's called, and I wouldn't want to lose that intuitiveness.  Similarly
'C-c C-o' currently opens the results of a code block, I also find this
very appealing as it allows for a uniform top-level interface across an
Org-mode document, be it a code block or a link.

Here are my reasons why I think leaving this keybinding is safe.

1) Unlike with shell/elisp links, the contents of code blocks is almost
   always visible right under the user's point.  So it is less likely to
   evaluate something w/o having any idea what you are evaluating.

2) Adding a protection variable (e.g. org-confirm-babel-eval) means that
   the only users who could potentially evaluate a code block with a
   slip of the fingers would be users who have explicitly said that they
   want to be able to easily run code blocks without confirmation.

3) Emacs exposes a number of entry points into code evaluation.  M-!
   allows users to run shell commands, C-M-x evaluate the elisp at
   point, and these have not caused problems in the past.

>
> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>    should be optional.
>
> 6. A section in the manual on code execution and associated security
>    risks in Org mode.  This is not only about babel, but also about
>    org-eval, org-eval-light, shell links and elisp links.  I have meant
>    to write this section for a long time and would be willing to
>    draft it. We could then refer to this section from a couple of
>    places in the docs, without cluttering the docs with disclaimers.
>

This sounds like a very good idea.  I'd be happy to help write such a
section.

>
> The reason for 4 and 5 is that I believe Org-mode users are trained
> to blindly press `C-c C-c' whenever they want to update something at
> point.  Matt's example of a blog post about `rm -rf' is a very
> realistic example for bad code being evaluated by mistake, not even
> due to malicious cations.  I belive that a special key for this
> action would gove a good measure of protection.
>

As I mentioned, I personally feel that an org-confirm-babel-eval
variable is sufficient protection.  I think it's safe to assume that if
a user has explicitly customized that variable, then they know what
they're doing and trust themselves to execute code responsibly.  I think
it's likely that the casual Org-babel user would never customize this
variable, which seems to me entirely appropriate.

>
> This is what I think - please let me know if you think I am overdoing
> it.
>

So to summarize, I think that the combination of (1), (2) and (6),
should be sufficient to protect users from accidental code evaluation.
Please let me know what you think, I am of course looking to compromise
and I fully understand that the general consensus may be that we need
more layers of protection.

Best -- Eric

>
> - Carsten
>
>
> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>
>> Hi Eric,
>>
>> Thanks again for all the work that you, Dan, and Tom have put into
>> org-babel. I'm glad to see it become part of org-mode!
>>
>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>
>>> 2) Babel will now be loaded by default along with the rest of Org-
>>> mode.
>>>   This means that *everyone* currently using babel will need to
>>> change
>>>   their Emacs config and remove the (require 'org-babel-int) and/or
>>>   (require 'org-babel) lines.
>>
>> I would like to request that org-babel be made an optional module. I
>> ask
>> this as someone who uses org-babel regularly. Here are my reasons:
>>
>>  - Org-babel adds rather specific and complex functionality to org-
>> mode
>>    that those who use it as a simple outliner and todo manager do not
>>    require. (In other words, an option to turn it off might be nice
>> for
>>    those who are worried about "feature creep.")
>>
>>  - Org-babel increases the risk of accidentally executing malicious or
>>    dangerous code when typing C-c C-c on a src block or exporting a
>>    file. Perhaps users should activate it only after they understand
>>    the risks.
>>
>>    + For instance, I might write a blog post warning about the dangers
>>      of typing "rm -rf ~/". If I put this between #+begin_src sh
>>      and #+end_src and unthinkingly hit C-c C-c, I would be in
>> trouble.
>>      I believe this is the reason for the variables
>>      org-confirm-shell-link-function and
>>      org-confirm-elisp-link-function.
>>
>>    + This is admitted a bit far-fetched as an example, as it would
>>      require one to have loaded ob-sh.el. But since elisp execution is
>>      activated by default, there remain opportunities for unwittingly
>>      executing code that is meant for other purposes (e.g., warnings,
>>      examples, etc.).
>>
>>>   Support for evaluating emacs-lisp code blocks is loaded by default.
>>>   All other languages will need to be required explicitly.  To
>>> conform
>>>   to Emacs filename specifications all language require lines have
>>> been
>>>   shortened from e.g.
>>>
>>>   (require 'org-babel-sh)
>>>
>>>   to
>>>
>>>   (require 'ob-sh)
>>
>> When I run make clean && make && make install I find that the language
>> directory is not installed. Does the langs directory require a manual
>> installation?
>>
>> Also, with make install, the ob-* files are installed on the same
>> level
>> as the org-files, yet lines 108-114 in org.el indicate that they
>> should
>> be installed in a babel subdirectory.
>>
>> Thanks!
>> Matt
>>
>> _______________________________________________
>> 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
>
> - Carsten

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

[Dan Davison]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Carsten, Matt, Scott,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Hi Matt, hi Eric,
>>
>> Matt, thanks a lot for bringing this up.  This is indeed a very
>> important and serious issue.  We need to address it.  We need to
>> step back and reconsider this carefully.
>>
>> Don't get me wrong, I absolutely think that Org Babel should give
>> you enough rope to hang yourself.  But we have to make sure that
>> this will not happen to a happy and unsuspecting Org mode, or even
>> an unsuspecting Emacs user who by chance opens a file with extension
>> .org.
>>
>> I remember very well when  first realized that shell links could
>> really affect you badly.  It scared me.
>>
>> You main proposal was to make Org Babel an optional module.
>> This will not solve the problem fully, I think, because we also
>> don't want that people who turn it on automatically commit
>> to potentially dangerous operations.  There is a lot of good stuff
>> in Babel which has nothing to do with code evaluation.
>>
>> Here is what I propose (several items are similar to what Eric proposes)
>>
>> 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.

>
>>
>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>    function
>>    This should by default query for confirmation on any org-babel
>>    code execution, and can be configured to shut up by people who know
>>    what they are doing.
>>
>
> Sounds good, I think this is a reasonable safety measure.

Yes, I think this is the key. Other than the doubts expressed above I
agree with what Eric wrote.

Dan

>
>>
>> 3. Not loading emacs lisp evaluation by default.
>>
>
> I would push back on this point.  Largely because we have now crossed
> the like to where it is impossible to play with a code block w/o first
> dropping down to your configuration files, and evaluating require
> statements.
>
>>
>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>    for example `C-c C-v e'.  This should be documented as the default
>>    key for this operation.
>>
>
> Hmm, I'm less enthusiastic about this point and point 5.  I really like
> how 'C-c C-c' naturally does whatever-I-want given the context in which
> it's called, and I wouldn't want to lose that intuitiveness.  Similarly
> 'C-c C-o' currently opens the results of a code block, I also find this
> very appealing as it allows for a uniform top-level interface across an
> Org-mode document, be it a code block or a link.
>
> Here are my reasons why I think leaving this keybinding is safe.
>
> 1) Unlike with shell/elisp links, the contents of code blocks is almost
>    always visible right under the user's point.  So it is less likely to
>    evaluate something w/o having any idea what you are evaluating.
>
> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means that
>    the only users who could potentially evaluate a code block with a
>    slip of the fingers would be users who have explicitly said that they
>    want to be able to easily run code blocks without confirmation.
>
> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>    allows users to run shell commands, C-M-x evaluate the elisp at
>    point, and these have not caused problems in the past.
>
>>
>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>    should be optional.
>>
>> 6. A section in the manual on code execution and associated security
>>    risks in Org mode.  This is not only about babel, but also about
>>    org-eval, org-eval-light, shell links and elisp links.  I have meant
>>    to write this section for a long time and would be willing to
>>    draft it. We could then refer to this section from a couple of
>>    places in the docs, without cluttering the docs with disclaimers.
>>
>
> This sounds like a very good idea.  I'd be happy to help write such a
> section.
>
>>
>> The reason for 4 and 5 is that I believe Org-mode users are trained
>> to blindly press `C-c C-c' whenever they want to update something at
>> point.  Matt's example of a blog post about `rm -rf' is a very
>> realistic example for bad code being evaluated by mistake, not even
>> due to malicious cations.  I belive that a special key for this
>> action would gove a good measure of protection.
>>
>
> As I mentioned, I personally feel that an org-confirm-babel-eval
> variable is sufficient protection.  I think it's safe to assume that if
> a user has explicitly customized that variable, then they know what
> they're doing and trust themselves to execute code responsibly.  I think
> it's likely that the casual Org-babel user would never customize this
> variable, which seems to me entirely appropriate.
>
>>
>> This is what I think - please let me know if you think I am overdoing
>> it.
>>
>
> So to summarize, I think that the combination of (1), (2) and (6),
> should be sufficient to protect users from accidental code evaluation.
> Please let me know what you think, I am of course looking to compromise
> and I fully understand that the general consensus may be that we need
> more layers of protection.
>
> Best -- Eric
>
>>
>> - Carsten
>>
>>
>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>
>>> Hi Eric,
>>>
>>> Thanks again for all the work that you, Dan, and Tom have put into
>>> org-babel. I'm glad to see it become part of org-mode!
>>>
>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>
>>>> 2) Babel will now be loaded by default along with the rest of Org-
>>>> mode.
>>>>   This means that *everyone* currently using babel will need to
>>>> change
>>>>   their Emacs config and remove the (require 'org-babel-int) and/or
>>>>   (require 'org-babel) lines.
>>>
>>> I would like to request that org-babel be made an optional module. I
>>> ask
>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>
>>>  - Org-babel adds rather specific and complex functionality to org-
>>> mode
>>>    that those who use it as a simple outliner and todo manager do not
>>>    require. (In other words, an option to turn it off might be nice
>>> for
>>>    those who are worried about "feature creep.")
>>>
>>>  - Org-babel increases the risk of accidentally executing malicious or
>>>    dangerous code when typing C-c C-c on a src block or exporting a
>>>    file. Perhaps users should activate it only after they understand
>>>    the risks.
>>>
>>>    + For instance, I might write a blog post warning about the dangers
>>>      of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>      and #+end_src and unthinkingly hit C-c C-c, I would be in
>>> trouble.
>>>      I believe this is the reason for the variables
>>>      org-confirm-shell-link-function and
>>>      org-confirm-elisp-link-function.
>>>
>>>    + This is admitted a bit far-fetched as an example, as it would
>>>      require one to have loaded ob-sh.el. But since elisp execution is
>>>      activated by default, there remain opportunities for unwittingly
>>>      executing code that is meant for other purposes (e.g., warnings,
>>>      examples, etc.).
>>>
>>>>   Support for evaluating emacs-lisp code blocks is loaded by default.
>>>>   All other languages will need to be required explicitly.  To
>>>> conform
>>>>   to Emacs filename specifications all language require lines have
>>>> been
>>>>   shortened from e.g.
>>>>
>>>>   (require 'org-babel-sh)
>>>>
>>>>   to
>>>>
>>>>   (require 'ob-sh)
>>>
>>> When I run make clean && make && make install I find that the language
>>> directory is not installed. Does the langs directory require a manual
>>> installation?
>>>
>>> Also, with make install, the ob-* files are installed on the same
>>> level
>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>> should
>>> be installed in a babel subdirectory.
>>>
>>> Thanks!
>>> Matt
>>>
>>> _______________________________________________
>>> 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
>>
>> - Carsten
>
> _______________________________________________
> 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

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

[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

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

[Eric Schulte]

Matt Lundin <mdl@imapmail.org> writes:

[...]
>
> When I run make clean && make && make install I find that the language
> directory is not installed. Does the langs directory require a manual
> installation?
>
> Also, with make install, the ob-* files are installed on the same level
> as the org-files, yet lines 108-114 in org.el indicate that they should
> be installed in a babel subdirectory.
>
> Thanks!
> Matt

Hi Matt,

This should now be fixed.

Thanks -- Eric

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

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

Hi,

To add some concreteness to my suggestions I'm attaching to possible
patches.

The first introduces a global `org-confirm-babel-evaluate' variable
which defaults to t, meaning all code block evaluations will require
explicit confirmation from the user.

The second patch adds an `org-babel-disable:emacs-lisp' function which
can be called from a users configuration to ensure that *no* emacs-lisp
code blocks can be evaluated on the user's system.

Best -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-babel-evaluation-of-code-blocks-now-requires-confirm.patch --]
[-- Type: text/x-diff, Size: 6137 bytes --]

From 993dda2b88220a994422becdef11773986094ce6 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Wed, 30 Jun 2010 12:25:22 -0700
Subject: [PATCH 1/2] babel: evaluation of code blocks now requires confirmation

* lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to
  control evaluation of code blocks, default value it t, meaning all
  code block evaluation requires confirmation

  (org-babel-confirm-evaluate): function used to request confirmation
  of code block evaluation from the user

  (org-babel-execute-src-block-maybe): now requires explicit user
  confirmation before evaluating a code block

  (org-babel-open-src-block-result): now requires explicit user
  confirmation before evaluating a code block

* lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block
  evaluation behavior
---
 lisp/babel/ob.el |   76 +++++++++++++++++++++++++++++++++++++----------------
 lisp/org.el      |    7 ++++-
 2 files changed, 59 insertions(+), 24 deletions(-)

diff --git a/lisp/babel/ob.el b/lisp/babel/ob.el
index 6a42bcc..e2ffd67 100644
--- a/lisp/babel/ob.el
+++ b/lisp/babel/ob.el
@@ -61,6 +61,18 @@
 (declare-function org-babel-ref-variables "ob-ref" (params))
 (declare-function org-babel-ref-resolve-reference "ob-ref" (ref &optional params))
 
+(defcustom org-confirm-babel-evaluate t
+  "Require confirmation before interactively evaluating code
+blocks in Org-mode buffers.  The default value of this variable
+is t, meaning confirmation is required for any code block
+evaluation.  This variable can be set to nil to inhibit any
+future confirmation requests.
+
+Note disabling confirmation may result in accidental evaluation
+of potentially harmful code."
+  :group 'org-babel
+  :type 'boolean)
+
 (defvar org-babel-source-name-regexp
   "^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]*"
   "Regular expression used to match a source name line.")
@@ -134,6 +146,19 @@ added to the header-arguments-alist."
           (org-babel-parse-inline-src-block-match)
         nil))))
 
+(defun org-babel-confirm-evaluate (&optional info)
+  "Confirm that the user wishes to evaluate the code block
+defined by INFO.  This behavior can be suppressed by setting the
+value of `org-confirm-babel-evaluate' to nil, in which case all
+future interactive code block evaluations will proceed without
+any confirmation from the user.
+
+Note disabling confirmation may result in accidental evaluation
+of potentially harmful code."
+  (or (not org-confirm-babel-evaluate)
+      (yes-or-no-p (format "Evaluate this%scode on your system?"
+			   (if info (format " %s " (nth 0 info)) " ")))))
+
 ;;;###autoload
 (defun org-babel-execute-src-block-maybe ()
   "Detect if this is context for a org-babel src-block and if so
@@ -141,7 +166,10 @@ then run `org-babel-execute-src-block'."
   (interactive)
   (let ((info (org-babel-get-src-block-info)))
     (if info
-        (progn (org-babel-execute-src-block current-prefix-arg info) t) nil)))
+	(if (org-babel-confirm-evaluate info)
+	    (progn (org-babel-execute-src-block current-prefix-arg info) t)
+	  (error "evaluation aborted"))
+      nil)))
 
 (add-hook 'org-ctrl-c-ctrl-c-hook 'org-babel-execute-src-block-maybe)
 
@@ -379,28 +407,30 @@ argument RE-RUN the source-code block is evaluated even if
 results already exist."
   (interactive "P")
   (when (org-babel-get-src-block-info)
-    (save-excursion
-      ;; go to the results, if there aren't any then run the block
-      (goto-char (or (and (not re-run) (org-babel-where-is-src-block-result))
-                     (progn (org-babel-execute-src-block)
-                            (org-babel-where-is-src-block-result))))
-      (end-of-line 1)
-      (while (looking-at "[\n\r\t\f ]") (forward-char 1))
-      ;; open the results
-      (if (looking-at org-bracket-link-regexp)
-          ;; file results
-          (org-open-at-point)
-        (let ((results (org-babel-read-result)))
-          (flet ((echo-res (result)
-                           (if (stringp result) result (format "%S" result))))
-            (pop-to-buffer (get-buffer-create "org-babel-results"))
-            (delete-region (point-min) (point-max))
-            (if (listp results)
-                ;; table result
-                (insert (orgtbl-to-generic results '(:sep "\t" :fmt echo-res)))
-              ;; scalar result
-              (insert (echo-res results))))))
-      t)))
+    (if (org-babel-confirm-evaluate)
+	(save-excursion
+	  ;; go to the results, if there aren't any then run the block
+	  (goto-char (or (and (not re-run) (org-babel-where-is-src-block-result))
+			 (progn (org-babel-execute-src-block)
+				(org-babel-where-is-src-block-result))))
+	  (end-of-line 1)
+	  (while (looking-at "[\n\r\t\f ]") (forward-char 1))
+	  ;; open the results
+	  (if (looking-at org-bracket-link-regexp)
+	      ;; file results
+	      (org-open-at-point)
+	    (let ((results (org-babel-read-result)))
+	      (flet ((echo-res (result)
+			       (if (stringp result) result (format "%S" result))))
+		(pop-to-buffer (get-buffer-create "org-babel-results"))
+		(delete-region (point-min) (point-max))
+		(if (listp results)
+		    ;; table result
+		    (insert (orgtbl-to-generic results '(:sep "\t" :fmt echo-res)))
+		  ;; scalar result
+		  (insert (echo-res results))))))
+	  t)
+      (error "evaluation aborted"))))
 
 ;;;###autoload
 (defun org-babel-execute-buffer (&optional arg)
diff --git a/lisp/org.el b/lisp/org.el
index f2d9ade..22aaef8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17011,7 +17011,12 @@ This command does many different things, depending on context:
 - If the cursor is on a numbered item in a plain list, renumber the
   ordered list.
 
-- If the cursor is on a checkbox, toggle it."
+- If the cursor is on a checkbox, toggle it.
+
+- If the cursor is on a code block, evaluate it.  The variable
+  `org-confirm-babel-evaluate' can be used to control prompting
+  before code block evaluation, by default every code block
+  evaluation requires confirmation."
   (interactive "P")
   (let  ((org-enable-table-editor t))
     (cond
-- 
1.7.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-babel-added-function-for-completely-disabling-emacs-.patch --]
[-- Type: text/x-diff, Size: 1664 bytes --]

From a7c699331e4a86d5779cecec22de0a297cd13d1c Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Wed, 30 Jun 2010 12:37:07 -0700
Subject: [PATCH 2/2] babel: added function for completely disabling emacs-lisp code block evaluation

* lisp/babel/langs/ob-emacs-lisp.el (org-babel-disable:emacs-lisp):
  added function for completely disabling emacs-lisp code block
  evaluation, after this function is called emacs lisp code blocks
  will be note evaluable by Babel unless the ob-emacs-lisp file is
  re-loaded
---
 lisp/babel/langs/ob-emacs-lisp.el |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/lisp/babel/langs/ob-emacs-lisp.el b/lisp/babel/langs/ob-emacs-lisp.el
index 81ee22e..8ddb8c3 100644
--- a/lisp/babel/langs/ob-emacs-lisp.el
+++ b/lisp/babel/langs/ob-emacs-lisp.el
@@ -68,6 +68,17 @@
        (org-babel-pick-name (nth 4 processed-params) (cdr (assoc :colnames params)))
        (org-babel-pick-name (nth 5 processed-params) (cdr (assoc :rownames params)))))))
 
+(defun org-babel-disable:emacs-lisp ()
+  "This function can be used to disable evaluation of emacs-lisp
+code blocks.  Calling this function ensures that no emacs-lisp
+code blocks can be evaluated on your system unless
+`ob-emacs-lisp' is later explicitly loaded or required."
+  (interactive)
+  (defun org-babel-execute:emacs-lisp (body params)
+    (error "Emacs lisp evaluation is disabled."))
+  (defun org-babel-expand-body:emacs-lisp (body params &optional processed-params)
+    (error "Emacs lisp evaluation is disabled.")))
+
 (provide 'ob-emacs-lisp)
 
 ;; arch-tag: e9a3acca-dc84-472a-9f5a-23c35befbcd6
-- 
1.7.0.4


[-- Attachment #4: Type: text/plain, Size: 8384 bytes --]


"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi Carsten, Matt, Scott,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Hi Matt, hi Eric,
>>
>> Matt, thanks a lot for bringing this up.  This is indeed a very
>> important and serious issue.  We need to address it.  We need to
>> step back and reconsider this carefully.
>>
>> Don't get me wrong, I absolutely think that Org Babel should give
>> you enough rope to hang yourself.  But we have to make sure that
>> this will not happen to a happy and unsuspecting Org mode, or even
>> an unsuspecting Emacs user who by chance opens a file with extension
>> .org.
>>
>> I remember very well when  first realized that shell links could
>> really affect you badly.  It scared me.
>>
>> You main proposal was to make Org Babel an optional module.
>> This will not solve the problem fully, I think, because we also
>> don't want that people who turn it on automatically commit
>> to potentially dangerous operations.  There is a lot of good stuff
>> in Babel which has nothing to do with code evaluation.
>>
>> Here is what I propose (several items are similar to what Eric proposes)
>>
>> 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.
>
>>
>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>    function
>>    This should by default query for confirmation on any org-babel
>>    code execution, and can be configured to shut up by people who know
>>    what they are doing.
>>
>
> Sounds good, I think this is a reasonable safety measure.
>
>>
>> 3. Not loading emacs lisp evaluation by default.
>>
>
> I would push back on this point.  Largely because we have now crossed
> the like to where it is impossible to play with a code block w/o first
> dropping down to your configuration files, and evaluating require
> statements.
>
>>
>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>    for example `C-c C-v e'.  This should be documented as the default
>>    key for this operation.
>>
>
> Hmm, I'm less enthusiastic about this point and point 5.  I really like
> how 'C-c C-c' naturally does whatever-I-want given the context in which
> it's called, and I wouldn't want to lose that intuitiveness.  Similarly
> 'C-c C-o' currently opens the results of a code block, I also find this
> very appealing as it allows for a uniform top-level interface across an
> Org-mode document, be it a code block or a link.
>
> Here are my reasons why I think leaving this keybinding is safe.
>
> 1) Unlike with shell/elisp links, the contents of code blocks is almost
>    always visible right under the user's point.  So it is less likely to
>    evaluate something w/o having any idea what you are evaluating.
>
> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means that
>    the only users who could potentially evaluate a code block with a
>    slip of the fingers would be users who have explicitly said that they
>    want to be able to easily run code blocks without confirmation.
>
> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>    allows users to run shell commands, C-M-x evaluate the elisp at
>    point, and these have not caused problems in the past.
>
>>
>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>    should be optional.
>>
>> 6. A section in the manual on code execution and associated security
>>    risks in Org mode.  This is not only about babel, but also about
>>    org-eval, org-eval-light, shell links and elisp links.  I have meant
>>    to write this section for a long time and would be willing to
>>    draft it. We could then refer to this section from a couple of
>>    places in the docs, without cluttering the docs with disclaimers.
>>
>
> This sounds like a very good idea.  I'd be happy to help write such a
> section.
>
>>
>> The reason for 4 and 5 is that I believe Org-mode users are trained
>> to blindly press `C-c C-c' whenever they want to update something at
>> point.  Matt's example of a blog post about `rm -rf' is a very
>> realistic example for bad code being evaluated by mistake, not even
>> due to malicious cations.  I belive that a special key for this
>> action would gove a good measure of protection.
>>
>
> As I mentioned, I personally feel that an org-confirm-babel-eval
> variable is sufficient protection.  I think it's safe to assume that if
> a user has explicitly customized that variable, then they know what
> they're doing and trust themselves to execute code responsibly.  I think
> it's likely that the casual Org-babel user would never customize this
> variable, which seems to me entirely appropriate.
>
>>
>> This is what I think - please let me know if you think I am overdoing
>> it.
>>
>
> So to summarize, I think that the combination of (1), (2) and (6),
> should be sufficient to protect users from accidental code evaluation.
> Please let me know what you think, I am of course looking to compromise
> and I fully understand that the general consensus may be that we need
> more layers of protection.
>
> Best -- Eric
>
>>
>> - Carsten
>>
>>
>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>
>>> Hi Eric,
>>>
>>> Thanks again for all the work that you, Dan, and Tom have put into
>>> org-babel. I'm glad to see it become part of org-mode!
>>>
>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>
>>>> 2) Babel will now be loaded by default along with the rest of Org-
>>>> mode.
>>>>   This means that *everyone* currently using babel will need to
>>>> change
>>>>   their Emacs config and remove the (require 'org-babel-int) and/or
>>>>   (require 'org-babel) lines.
>>>
>>> I would like to request that org-babel be made an optional module. I
>>> ask
>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>
>>>  - Org-babel adds rather specific and complex functionality to org-
>>> mode
>>>    that those who use it as a simple outliner and todo manager do not
>>>    require. (In other words, an option to turn it off might be nice
>>> for
>>>    those who are worried about "feature creep.")
>>>
>>>  - Org-babel increases the risk of accidentally executing malicious or
>>>    dangerous code when typing C-c C-c on a src block or exporting a
>>>    file. Perhaps users should activate it only after they understand
>>>    the risks.
>>>
>>>    + For instance, I might write a blog post warning about the dangers
>>>      of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>      and #+end_src and unthinkingly hit C-c C-c, I would be in
>>> trouble.
>>>      I believe this is the reason for the variables
>>>      org-confirm-shell-link-function and
>>>      org-confirm-elisp-link-function.
>>>
>>>    + This is admitted a bit far-fetched as an example, as it would
>>>      require one to have loaded ob-sh.el. But since elisp execution is
>>>      activated by default, there remain opportunities for unwittingly
>>>      executing code that is meant for other purposes (e.g., warnings,
>>>      examples, etc.).
>>>
>>>>   Support for evaluating emacs-lisp code blocks is loaded by default.
>>>>   All other languages will need to be required explicitly.  To
>>>> conform
>>>>   to Emacs filename specifications all language require lines have
>>>> been
>>>>   shortened from e.g.
>>>>
>>>>   (require 'org-babel-sh)
>>>>
>>>>   to
>>>>
>>>>   (require 'ob-sh)
>>>
>>> When I run make clean && make && make install I find that the language
>>> directory is not installed. Does the langs directory require a manual
>>> installation?
>>>
>>> Also, with make install, the ob-* files are installed on the same
>>> level
>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>> should
>>> be installed in a babel subdirectory.
>>>
>>> Thanks!
>>> Matt
>>>
>>> _______________________________________________
>>> 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
>>
>> - Carsten

[-- Attachment #5: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

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

[Matthew Lundin]

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Matt Lundin <mdl@imapmail.org> writes:
>
> [...]
>>
>> When I run make clean && make && make install I find that the language
>> directory is not installed. Does the langs directory require a manual
>> installation?
>>
>> Also, with make install, the ob-* files are installed on the same level
>> as the org-files, yet lines 108-114 in org.el indicate that they should
>> be installed in a babel subdirectory.

> This should now be fixed.

Thanks. Everything was installed in the right place.

- Matt

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

[Stephan Schmitt]

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

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

[Matthew Lundin]

Dan Davison <dandavison7@gmail.com> writes:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> You main proposal was to make Org Babel an optional module.
>>> This will not solve the problem fully, I think, because we also
>>> don't want that people who turn it on automatically commit
>>> to potentially dangerous operations.  There is a lot of good stuff
>>> in Babel which has nothing to do with code evaluation.
>>>
>>> Here is what I propose (several items are similar to what Eric proposes)
>>>
>>> 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?

Thanks Dan for this clarification. My primary concern had to do with the
risk org-babel introduces of executing problematic code. This concern
has been largely allayed by Eric's recent addition of a default
yes-or-no-p prompt before executing code in source blocks, along with
the option of disabling elisp evaluation. (I still fear accidentally
executing code during export, but that has to do with my lack of
familiarity with inline-src-blocks, which are evaluated by default on
export.)

You certainly have a far better understanding than I do of the potential
org-babel offers for org-mode's core functionality. The package is
indeed small compared to other features, so load time should not be much
of an issue. I very much appreciate the ways in which you and Eric have
made org-babel modular, loading a minimal framework by default and
leaving the selection of languages up to the user. My concern, I
suppose, has to do with the ever-growing complexity of org-mode.
Wherever possible, I would prefer to give users the freedom *not* to
load modules they don't need. That may be not be possible or desirable
in this case. So I am eager to learn more about ways in which org-babel
can enhance and simplify the core features of org-mode.

Please don't take any of these concerns as criticism of a package from
which I already benefit immensely. Far be it from me to look askance at
such a useful gift!

Best,
Matt

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

[Carsten Dominik]

On Jun 30, 2010, at 7:01 PM, Dan Davison wrote:

> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Hi Carsten, Matt, Scott,
>>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Hi Matt, hi Eric,
>>>
>>> Matt, thanks a lot for bringing this up.  This is indeed a very
>>> important and serious issue.  We need to address it.  We need to
>>> step back and reconsider this carefully.
>>>
>>> Don't get me wrong, I absolutely think that Org Babel should give
>>> you enough rope to hang yourself.  But we have to make sure that
>>> this will not happen to a happy and unsuspecting Org mode, or even
>>> an unsuspecting Emacs user who by chance opens a file with extension
>>> .org.
>>>
>>> I remember very well when  first realized that shell links could
>>> really affect you badly.  It scared me.
>>>
>>> You main proposal was to make Org Babel an optional module.
>>> This will not solve the problem fully, I think, because we also
>>> don't want that people who turn it on automatically commit
>>> to potentially dangerous operations.  There is a lot of good stuff
>>> in Babel which has nothing to do with code evaluation.
>>>
>>> Here is what I propose (several items are similar to what Eric  
>>> proposes)
>>>
>>> 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?

Like Eric, I agree.

>
> 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.

:-)  Actually, in this specific area I had been thinking to
removing or at least deprecating shell and elisp links,
because the Org-babel way is much better and clearer to have
that code in a block, rather than hiding it in the invisible
part of of a link.

> 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.

Yes, I agree.  This is definitely the point of this integration.

- Carsten

>
>>
>>>
>>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>>   function
>>>   This should by default query for confirmation on any org-babel
>>>   code execution, and can be configured to shut up by people who  
>>> know
>>>   what they are doing.
>>>
>>
>> Sounds good, I think this is a reasonable safety measure.
>
> Yes, I think this is the key. Other than the doubts expressed above I
> agree with what Eric wrote.
>
> Dan
>
>>
>>>
>>> 3. Not loading emacs lisp evaluation by default.
>>>
>>
>> I would push back on this point.  Largely because we have now crossed
>> the like to where it is impossible to play with a code block w/o  
>> first
>> dropping down to your configuration files, and evaluating require
>> statements.
>>
>>>
>>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>>   for example `C-c C-v e'.  This should be documented as the default
>>>   key for this operation.
>>>
>>
>> Hmm, I'm less enthusiastic about this point and point 5.  I really  
>> like
>> how 'C-c C-c' naturally does whatever-I-want given the context in  
>> which
>> it's called, and I wouldn't want to lose that intuitiveness.   
>> Similarly
>> 'C-c C-o' currently opens the results of a code block, I also find  
>> this
>> very appealing as it allows for a uniform top-level interface  
>> across an
>> Org-mode document, be it a code block or a link.
>>
>> Here are my reasons why I think leaving this keybinding is safe.
>>
>> 1) Unlike with shell/elisp links, the contents of code blocks is  
>> almost
>>   always visible right under the user's point.  So it is less  
>> likely to
>>   evaluate something w/o having any idea what you are evaluating.
>>
>> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means  
>> that
>>   the only users who could potentially evaluate a code block with a
>>   slip of the fingers would be users who have explicitly said that  
>> they
>>   want to be able to easily run code blocks without confirmation.
>>
>> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>>   allows users to run shell commands, C-M-x evaluate the elisp at
>>   point, and these have not caused problems in the past.
>>
>>>
>>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>>   should be optional.
>>>
>>> 6. A section in the manual on code execution and associated security
>>>   risks in Org mode.  This is not only about babel, but also about
>>>   org-eval, org-eval-light, shell links and elisp links.  I have  
>>> meant
>>>   to write this section for a long time and would be willing to
>>>   draft it. We could then refer to this section from a couple of
>>>   places in the docs, without cluttering the docs with disclaimers.
>>>
>>
>> This sounds like a very good idea.  I'd be happy to help write such a
>> section.
>>
>>>
>>> The reason for 4 and 5 is that I believe Org-mode users are trained
>>> to blindly press `C-c C-c' whenever they want to update something at
>>> point.  Matt's example of a blog post about `rm -rf' is a very
>>> realistic example for bad code being evaluated by mistake, not even
>>> due to malicious cations.  I belive that a special key for this
>>> action would gove a good measure of protection.
>>>
>>
>> As I mentioned, I personally feel that an org-confirm-babel-eval
>> variable is sufficient protection.  I think it's safe to assume  
>> that if
>> a user has explicitly customized that variable, then they know what
>> they're doing and trust themselves to execute code responsibly.  I  
>> think
>> it's likely that the casual Org-babel user would never customize this
>> variable, which seems to me entirely appropriate.
>>
>>>
>>> This is what I think - please let me know if you think I am  
>>> overdoing
>>> it.
>>>
>>
>> So to summarize, I think that the combination of (1), (2) and (6),
>> should be sufficient to protect users from accidental code  
>> evaluation.
>> Please let me know what you think, I am of course looking to  
>> compromise
>> and I fully understand that the general consensus may be that we need
>> more layers of protection.
>>
>> Best -- Eric
>>
>>>
>>> - Carsten
>>>
>>>
>>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> Thanks again for all the work that you, Dan, and Tom have put into
>>>> org-babel. I'm glad to see it become part of org-mode!
>>>>
>>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>>
>>>>> 2) Babel will now be loaded by default along with the rest of Org-
>>>>> mode.
>>>>>  This means that *everyone* currently using babel will need to
>>>>> change
>>>>>  their Emacs config and remove the (require 'org-babel-int) and/or
>>>>>  (require 'org-babel) lines.
>>>>
>>>> I would like to request that org-babel be made an optional  
>>>> module. I
>>>> ask
>>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>>
>>>> - Org-babel adds rather specific and complex functionality to org-
>>>> mode
>>>>   that those who use it as a simple outliner and todo manager do  
>>>> not
>>>>   require. (In other words, an option to turn it off might be nice
>>>> for
>>>>   those who are worried about "feature creep.")
>>>>
>>>> - Org-babel increases the risk of accidentally executing  
>>>> malicious or
>>>>   dangerous code when typing C-c C-c on a src block or exporting a
>>>>   file. Perhaps users should activate it only after they understand
>>>>   the risks.
>>>>
>>>>   + For instance, I might write a blog post warning about the  
>>>> dangers
>>>>     of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>>     and #+end_src and unthinkingly hit C-c C-c, I would be in
>>>> trouble.
>>>>     I believe this is the reason for the variables
>>>>     org-confirm-shell-link-function and
>>>>     org-confirm-elisp-link-function.
>>>>
>>>>   + This is admitted a bit far-fetched as an example, as it would
>>>>     require one to have loaded ob-sh.el. But since elisp  
>>>> execution is
>>>>     activated by default, there remain opportunities for  
>>>> unwittingly
>>>>     executing code that is meant for other purposes (e.g.,  
>>>> warnings,
>>>>     examples, etc.).
>>>>
>>>>>  Support for evaluating emacs-lisp code blocks is loaded by  
>>>>> default.
>>>>>  All other languages will need to be required explicitly.  To
>>>>> conform
>>>>>  to Emacs filename specifications all language require lines have
>>>>> been
>>>>>  shortened from e.g.
>>>>>
>>>>>  (require 'org-babel-sh)
>>>>>
>>>>>  to
>>>>>
>>>>>  (require 'ob-sh)
>>>>
>>>> When I run make clean && make && make install I find that the  
>>>> language
>>>> directory is not installed. Does the langs directory require a  
>>>> manual
>>>> installation?
>>>>
>>>> Also, with make install, the ob-* files are installed on the same
>>>> level
>>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>>> should
>>>> be installed in a babel subdirectory.
>>>>
>>>> Thanks!
>>>> Matt
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> - Carsten
>>
>> _______________________________________________
>> 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

- Carsten

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

[Carsten Dominik]

Hi everyone,

first of all, I think it is clear that I may have overreacted
with the "6 point plan".  But it is good that we are having
this discussion.

On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:

> Hi Carsten, Matt, Scott,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Hi Matt, hi Eric,
>>
>> Matt, thanks a lot for bringing this up.  This is indeed a very
>> important and serious issue.  We need to address it.  We need to
>> step back and reconsider this carefully.
>>
>> Don't get me wrong, I absolutely think that Org Babel should give
>> you enough rope to hang yourself.  But we have to make sure that
>> this will not happen to a happy and unsuspecting Org mode, or even
>> an unsuspecting Emacs user who by chance opens a file with extension
>> .org.
>>
>> I remember very well when  first realized that shell links could
>> really affect you badly.  It scared me.
>>
>> You main proposal was to make Org Babel an optional module.
>> This will not solve the problem fully, I think, because we also
>> don't want that people who turn it on automatically commit
>> to potentially dangerous operations.  There is a lot of good stuff
>> in Babel which has nothing to do with code evaluation.
>>
>> Here is what I propose (several items are similar to what Eric  
>> proposes)
>>
>> 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.

Actually, following Dan's argument, I am paddling back on this one.
Lets just keep it on.

Instead of having a function to unload emacs-lisp, maybe a good way
would be a customize option org-babel-load-languages with a checkbox
for each language, emacs-lisp on by default.  This would make it easy fo
people to select the languages they want, without having to add
several require statements to .emacs.

>>
>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>  function
>>  This should by default query for confirmation on any org-babel
>>  code execution, and can be configured to shut up by people who know
>>  what they are doing.
>>
>
> Sounds good, I think this is a reasonable safety measure.
>
>>
>> 3. Not loading emacs lisp evaluation by default.
>>
>
> I would push back on this point.  Largely because we have now crossed
> the like to where it is impossible to play with a code block w/o first
> dropping down to your configuration files, and evaluating require
> statements.
>
>>
>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>  for example `C-c C-v e'.  This should be documented as the default
>>  key for this operation.
>>
>
> Hmm, I'm less enthusiastic about this point and point 5.  I really  
> like
> how 'C-c C-c' naturally does whatever-I-want given the context in  
> which
> it's called, and I wouldn't want to lose that intuitiveness.   
> Similarly
> 'C-c C-o' currently opens the results of a code block, I also find  
> this
> very appealing as it allows for a uniform top-level interface across  
> an
> Org-mode document, be it a code block or a link.
>
> Here are my reasons why I think leaving this keybinding is safe.
>
> 1) Unlike with shell/elisp links, the contents of code blocks is  
> almost
>  always visible right under the user's point.  So it is less likely to
>  evaluate something w/o having any idea what you are evaluating.
>
> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means  
> that
>  the only users who could potentially evaluate a code block with a
>  slip of the fingers would be users who have explicitly said that they
>  want to be able to easily run code blocks without confirmation.
>
> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>  allows users to run shell commands, C-M-x evaluate the elisp at
>  point, and these have not caused problems in the past.

These are all very well taken points.  And I agree that a somewhat
regular Org-mode user should be protected by this well enough.

There are actually two kinds of users and two levels where
we need to think about this.

1. I am worried about is this:  Org mode (including Babel)
will soon be part of Emacs an be shipped to a very large number of
people who have nothing to do with Org mode and might pick a file
of the web to try playing with it.  I want to protect these users and
also us, as the Org mode community, from a stupid accident happening
like that. But, in fact, a yes-or-no-p confirmation would probably
cover this well enough. OK for this part.  BTW, Eric,
I think this confirmation variable should also be allowed to take
a function with a two arguments, the language of the snippet
and the snippet.  Users could then write a function which would
get confirmation for some snippets, but not for others.

2. The other thing is that I am afraid of myself in this context.
I envision myself turning off the check eval confirmation check sooner
rather than later because I don't like to press the confirmation key
all the time.  Repetitive things like this annoy me and I turn them off.
So I am happily working with code in a document fine.

Later, I see myself accidentally pressing C-c C-c in a place where I did
not mean to press it.  Like in Matt's example, this could be a blog post
or any other document where I have some source code examples.
I press key combinations with C-c *so* many times
a day that a couple of `C-c C-c' come up by accident every day.
In fact, in this context I am more worried about `C-c C-c' than `C-c C- 
o'
This is why I was proposing to not have this in C-c C-c (and, now
you mention it, in C-c C-o) by default.  I definitely think
that it would be good to give users a variable to not include
these into `C-c C-c' and `C-c C-o'.  Having additional bindings
for these two commands in the `C-c C-v' map would not hurt in
any case.

On the other hand, I totally see how C-c C-c is a great and
natural binding if you wan to work with source code, of cause,
and I do understand why you defend it and want to have it in by
default.

So in summary, I think I could be fine with a situation
where the variable I just described exists and is set
so that C-c C-c and C-c C-o do the evaluation, and where
the issues are clearly documented.

- Carsten



>
>>
>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>  should be optional.
>>
>> 6. A section in the manual on code execution and associated security
>>  risks in Org mode.  This is not only about babel, but also about
>>  org-eval, org-eval-light, shell links and elisp links.  I have meant
>>  to write this section for a long time and would be willing to
>>  draft it. We could then refer to this section from a couple of
>>  places in the docs, without cluttering the docs with disclaimers.
>>
>
> This sounds like a very good idea.  I'd be happy to help write such a
> section.
>
>>
>> The reason for 4 and 5 is that I believe Org-mode users are trained
>> to blindly press `C-c C-c' whenever they want to update something at
>> point.  Matt's example of a blog post about `rm -rf' is a very
>> realistic example for bad code being evaluated by mistake, not even
>> due to malicious cations.  I belive that a special key for this
>> action would gove a good measure of protection.
>>
>
> As I mentioned, I personally feel that an org-confirm-babel-eval
> variable is sufficient protection.  I think it's safe to assume that  
> if
> a user has explicitly customized that variable, then they know what
> they're doing and trust themselves to execute code responsibly.  I  
> think
> it's likely that the casual Org-babel user would never customize this
> variable, which seems to me entirely appropriate.
>
>>
>> This is what I think - please let me know if you think I am overdoing
>> it.
>>
>
> So to summarize, I think that the combination of (1), (2) and (6),
> should be sufficient to protect users from accidental code evaluation.
> Please let me know what you think, I am of course looking to  
> compromise
> and I fully understand that the general consensus may be that we need
> more layers of protection.
>
> Best -- Eric
>
>>
>> - Carsten
>>
>>
>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>
>>> Hi Eric,
>>>
>>> Thanks again for all the work that you, Dan, and Tom have put into
>>> org-babel. I'm glad to see it become part of org-mode!
>>>
>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>
>>>> 2) Babel will now be loaded by default along with the rest of Org-
>>>> mode.
>>>> This means that *everyone* currently using babel will need to
>>>> change
>>>> their Emacs config and remove the (require 'org-babel-int) and/or
>>>> (require 'org-babel) lines.
>>>
>>> I would like to request that org-babel be made an optional module. I
>>> ask
>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>
>>> - Org-babel adds rather specific and complex functionality to org-
>>> mode
>>>  that those who use it as a simple outliner and todo manager do not
>>>  require. (In other words, an option to turn it off might be nice
>>> for
>>>  those who are worried about "feature creep.")
>>>
>>> - Org-babel increases the risk of accidentally executing malicious  
>>> or
>>>  dangerous code when typing C-c C-c on a src block or exporting a
>>>  file. Perhaps users should activate it only after they understand
>>>  the risks.
>>>
>>>  + For instance, I might write a blog post warning about the dangers
>>>    of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>    and #+end_src and unthinkingly hit C-c C-c, I would be in
>>> trouble.
>>>    I believe this is the reason for the variables
>>>    org-confirm-shell-link-function and
>>>    org-confirm-elisp-link-function.
>>>
>>>  + This is admitted a bit far-fetched as an example, as it would
>>>    require one to have loaded ob-sh.el. But since elisp execution is
>>>    activated by default, there remain opportunities for unwittingly
>>>    executing code that is meant for other purposes (e.g., warnings,
>>>    examples, etc.).
>>>
>>>> Support for evaluating emacs-lisp code blocks is loaded by default.
>>>> All other languages will need to be required explicitly.  To
>>>> conform
>>>> to Emacs filename specifications all language require lines have
>>>> been
>>>> shortened from e.g.
>>>>
>>>> (require 'org-babel-sh)
>>>>
>>>> to
>>>>
>>>> (require 'ob-sh)
>>>
>>> When I run make clean && make && make install I find that the  
>>> language
>>> directory is not installed. Does the langs directory require a  
>>> manual
>>> installation?
>>>
>>> Also, with make install, the ob-* files are installed on the same
>>> level
>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>> should
>>> be installed in a babel subdirectory.
>>>
>>> Thanks!
>>> Matt
>>>
>>> _______________________________________________
>>> 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
>>
>> - Carsten
>
> _______________________________________________
> 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

- Carsten

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

[Eric Schulte]

Hi,

Thanks for finding such a good compromises solution.  This new plan
looks great to me, specifics below

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi everyone,
>
> first of all, I think it is clear that I may have overreacted
> with the "6 point plan".  But it is good that we are having
> this discussion.
>
> On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:
>
>> Hi Carsten, Matt, Scott,
>>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Hi Matt, hi Eric,
>>>
>>> Matt, thanks a lot for bringing this up.  This is indeed a very
>>> important and serious issue.  We need to address it.  We need to
>>> step back and reconsider this carefully.
>>>
>>> Don't get me wrong, I absolutely think that Org Babel should give
>>> you enough rope to hang yourself.  But we have to make sure that
>>> this will not happen to a happy and unsuspecting Org mode, or even
>>> an unsuspecting Emacs user who by chance opens a file with extension
>>> .org.
>>>
>>> I remember very well when  first realized that shell links could
>>> really affect you badly.  It scared me.
>>>
>>> You main proposal was to make Org Babel an optional module.
>>> This will not solve the problem fully, I think, because we also
>>> don't want that people who turn it on automatically commit
>>> to potentially dangerous operations.  There is a lot of good stuff
>>> in Babel which has nothing to do with code evaluation.
>>>
>>> Here is what I propose (several items are similar to what Eric
>>> proposes)
>>>
>>> 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.
>
> Actually, following Dan's argument, I am paddling back on this one.
> Lets just keep it on.
>
> Instead of having a function to unload emacs-lisp, maybe a good way
> would be a customize option org-babel-load-languages with a checkbox
> for each language, emacs-lisp on by default.  This would make it easy fo
> people to select the languages they want, without having to add
> several require statements to .emacs.
>

This sounds like a good idea, such a variable would also play the
important role of advertising what languages currently support execution
in Babel.  One issue with this setup is that I think languages which do
not have FSF attribution (currently only oz) would still require an
explicit `require' statement, however that shouldn't be too surprising
as those statements live in the contrib directory, and users should be
used to having to explicitly require functionality located in contrib.

One nice thing about this setup is that it shouldn't break user's
current config (existing `require' statements will still work).

>
>>>
>>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>>  function
>>>  This should by default query for confirmation on any org-babel
>>>  code execution, and can be configured to shut up by people who know
>>>  what they are doing.
>>>
>>
>> Sounds good, I think this is a reasonable safety measure.
>>
>>>
>>> 3. Not loading emacs lisp evaluation by default.
>>>
>>
>> I would push back on this point.  Largely because we have now crossed
>> the like to where it is impossible to play with a code block w/o first
>> dropping down to your configuration files, and evaluating require
>> statements.
>>
>>>
>>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>>  for example `C-c C-v e'.  This should be documented as the default
>>>  key for this operation.
>>>
>>
>> Hmm, I'm less enthusiastic about this point and point 5.  I really
>> like
>> how 'C-c C-c' naturally does whatever-I-want given the context in
>> which
>> it's called, and I wouldn't want to lose that intuitiveness.
>> Similarly
>> 'C-c C-o' currently opens the results of a code block, I also find
>> this
>> very appealing as it allows for a uniform top-level interface across
>> an
>> Org-mode document, be it a code block or a link.
>>
>> Here are my reasons why I think leaving this keybinding is safe.
>>
>> 1) Unlike with shell/elisp links, the contents of code blocks is
>> almost
>>  always visible right under the user's point.  So it is less likely to
>>  evaluate something w/o having any idea what you are evaluating.
>>
>> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means
>> that
>>  the only users who could potentially evaluate a code block with a
>>  slip of the fingers would be users who have explicitly said that they
>>  want to be able to easily run code blocks without confirmation.
>>
>> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>>  allows users to run shell commands, C-M-x evaluate the elisp at
>>  point, and these have not caused problems in the past.
>
> These are all very well taken points.  And I agree that a somewhat
> regular Org-mode user should be protected by this well enough.
>
> There are actually two kinds of users and two levels where
> we need to think about this.
>
> 1. I am worried about is this:  Org mode (including Babel)
> will soon be part of Emacs an be shipped to a very large number of
> people who have nothing to do with Org mode and might pick a file
> of the web to try playing with it.  I want to protect these users and
> also us, as the Org mode community, from a stupid accident happening
> like that. But, in fact, a yes-or-no-p confirmation would probably
> cover this well enough. OK for this part.  BTW, Eric,
> I think this confirmation variable should also be allowed to take
> a function with a two arguments, the language of the snippet
> and the snippet.  Users could then write a function which would
> get confirmation for some snippets, but not for others.
>

This sounds like a good idea.  I'll update the confirmation function as
you've described.  One possible issue here is that with complicated
setups, a single action could require multiple confirmations -- as
executing one code block can call on other code blocks as arguments, but
I think that behavior is required to ensure that the user is fully aware
of the full extent of the processes taking place.

>
> 2. The other thing is that I am afraid of myself in this context.
> I envision myself turning off the check eval confirmation check sooner
> rather than later because I don't like to press the confirmation key
> all the time.  Repetitive things like this annoy me and I turn them off.
> So I am happily working with code in a document fine.
>
> Later, I see myself accidentally pressing C-c C-c in a place where I did
> not mean to press it.  Like in Matt's example, this could be a blog post
> or any other document where I have some source code examples.
> I press key combinations with C-c *so* many times
> a day that a couple of `C-c C-c' come up by accident every day.
> In fact, in this context I am more worried about `C-c C-c' than `C-c
> C-
> o'
> This is why I was proposing to not have this in C-c C-c (and, now
> you mention it, in C-c C-o) by default.  I definitely think
> that it would be good to give users a variable to not include
> these into `C-c C-c' and `C-c C-o'.  Having additional bindings
> for these two commands in the `C-c C-v' map would not hurt in
> any case.
>
> On the other hand, I totally see how C-c C-c is a great and
> natural binding if you wan to work with source code, of cause,
> and I do understand why you defend it and want to have it in by
> default.
>

Thanks for your understanding on this point.

>
> So in summary, I think I could be fine with a situation
> where the variable I just described exists and is set
> so that C-c C-c and C-c C-o do the evaluation, and where
> the issues are clearly documented.
>

I see your point, and I think your proposed solution is a good
compromise.  I'll add C-c C-v keybindings for both evaluation and
opening of code blocks.  Also, I'll add a variable which can be used to
disable the binding of code block execution to C-c C-c.  We can also
mention this variable in the documentation for the confirmation
variable, so that as users disable block confirmation they will
(hopefully) read the documentation of the variable they are disabling,
and will stop and think "maybe in a world w/o confirmation, I'd feel
safer using a higher friction keybinding".

BTW: any suggestions for C-c C-v key bindings, I'm thinking of the
following, but there may be options with better ergonomics.
| C-c C-v e | for code block execution, mnemonic "execute" |
| C-c C-v o | for opening of results, mnemonic "open"      |

Thanks -- Eric

>
> - Carsten
>
>
>
>>
>>>
>>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>>  should be optional.
>>>
>>> 6. A section in the manual on code execution and associated security
>>>  risks in Org mode.  This is not only about babel, but also about
>>>  org-eval, org-eval-light, shell links and elisp links.  I have meant
>>>  to write this section for a long time and would be willing to
>>>  draft it. We could then refer to this section from a couple of
>>>  places in the docs, without cluttering the docs with disclaimers.
>>>
>>
>> This sounds like a very good idea.  I'd be happy to help write such a
>> section.
>>
>>>
>>> The reason for 4 and 5 is that I believe Org-mode users are trained
>>> to blindly press `C-c C-c' whenever they want to update something at
>>> point.  Matt's example of a blog post about `rm -rf' is a very
>>> realistic example for bad code being evaluated by mistake, not even
>>> due to malicious cations.  I belive that a special key for this
>>> action would gove a good measure of protection.
>>>
>>
>> As I mentioned, I personally feel that an org-confirm-babel-eval
>> variable is sufficient protection.  I think it's safe to assume that
>> if
>> a user has explicitly customized that variable, then they know what
>> they're doing and trust themselves to execute code responsibly.  I
>> think
>> it's likely that the casual Org-babel user would never customize this
>> variable, which seems to me entirely appropriate.
>>
>>>
>>> This is what I think - please let me know if you think I am overdoing
>>> it.
>>>
>>
>> So to summarize, I think that the combination of (1), (2) and (6),
>> should be sufficient to protect users from accidental code evaluation.
>> Please let me know what you think, I am of course looking to
>> compromise
>> and I fully understand that the general consensus may be that we need
>> more layers of protection.
>>
>> Best -- Eric
>>
>>>
>>> - Carsten
>>>
>>>
>>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> Thanks again for all the work that you, Dan, and Tom have put into
>>>> org-babel. I'm glad to see it become part of org-mode!
>>>>
>>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>>
>>>>> 2) Babel will now be loaded by default along with the rest of Org-
>>>>> mode.
>>>>> This means that *everyone* currently using babel will need to
>>>>> change
>>>>> their Emacs config and remove the (require 'org-babel-int) and/or
>>>>> (require 'org-babel) lines.
>>>>
>>>> I would like to request that org-babel be made an optional module. I
>>>> ask
>>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>>
>>>> - Org-babel adds rather specific and complex functionality to org-
>>>> mode
>>>>  that those who use it as a simple outliner and todo manager do not
>>>>  require. (In other words, an option to turn it off might be nice
>>>> for
>>>>  those who are worried about "feature creep.")
>>>>
>>>> - Org-babel increases the risk of accidentally executing malicious
>>>> or
>>>>  dangerous code when typing C-c C-c on a src block or exporting a
>>>>  file. Perhaps users should activate it only after they understand
>>>>  the risks.
>>>>
>>>>  + For instance, I might write a blog post warning about the dangers
>>>>    of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>>    and #+end_src and unthinkingly hit C-c C-c, I would be in
>>>> trouble.
>>>>    I believe this is the reason for the variables
>>>>    org-confirm-shell-link-function and
>>>>    org-confirm-elisp-link-function.
>>>>
>>>>  + This is admitted a bit far-fetched as an example, as it would
>>>>    require one to have loaded ob-sh.el. But since elisp execution is
>>>>    activated by default, there remain opportunities for unwittingly
>>>>    executing code that is meant for other purposes (e.g., warnings,
>>>>    examples, etc.).
>>>>
>>>>> Support for evaluating emacs-lisp code blocks is loaded by default.
>>>>> All other languages will need to be required explicitly.  To
>>>>> conform
>>>>> to Emacs filename specifications all language require lines have
>>>>> been
>>>>> shortened from e.g.
>>>>>
>>>>> (require 'org-babel-sh)
>>>>>
>>>>> to
>>>>>
>>>>> (require 'ob-sh)
>>>>
>>>> When I run make clean && make && make install I find that the
>>>> language
>>>> directory is not installed. Does the langs directory require a
>>>> manual
>>>> installation?
>>>>
>>>> Also, with make install, the ob-* files are installed on the same
>>>> level
>>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>>> should
>>>> be installed in a babel subdirectory.
>>>>
>>>> Thanks!
>>>> Matt
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> - Carsten
>>
>> _______________________________________________
>> 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
>
> - Carsten

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

[Nick Dokos]

Carsten Dominik <carsten.dominik@gmail.com> wrote:

> 
> :-)  Actually, in this specific area I had been thinking to
> removing or at least deprecating shell and elisp links,
> because the Org-babel way is much better and clearer to have
> that code in a block, rather than hiding it in the invisible
> part of of a link.
> 

Here is an early vote [1] for *not* removing shell and elisp links.
Deprecation/documentation/scary warnings is fine with me, but I do use
these kinds of links and I'd like to be able to continue using them.

Thanks,
Nick

[1] and if necessary, I can vote often too :-), but I don't know if the
vote early/vote often model would work here...

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

[Sébastien Vauban]

Hi Nick,

Nick Dokos wrote:
> Carsten Dominik <carsten.dominik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> 
>> :-) Actually, in this specific area I had been thinking to removing or at
>> least deprecating shell and elisp links, because the Org-babel way is much
>> better and clearer to have that code in a block, rather than hiding it in
>> the invisible part of of a link.
>
> Here is an early vote [1] for *not* removing shell and elisp links.
> Deprecation/documentation/scary warnings is fine with me, but I do use these
> kinds of links and I'd like to be able to continue using them.

For my own understanding of what more I could do that I don't even think of
right now, *if not indiscreet/private*, could you give a couple of
applications of such links?

Best regards,
  Seb

-- 
Sébastien Vauban


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

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

[Eric Schulte]

Hi,

Pursuant to the below, I've created a new "babel-safety" branch of the
repository.  It includes two new commits, the first of which implements
confirmation before *any* code block evaluation, adds the keybinds for
code block evaluation, and adds a documentation for disassociating code
block evaluation from C-c C-c.

,----[1d0b2f48c7f4b12b07dcfff0b5c1d29cc2c863bb]
| babel: evaluation of code blocks now requires confirmation
| 
| * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to
|   control evaluation of code blocks, default value it t, meaning all
|   code block evaluation requires confirmation
| 
|   (org-babel-confirm-evaluate): function used to request confirmation
|   of code block evaluation from the user
| 
|   (org-babel-execute-src-block): this function is the single point of
|   entry for evaluation of code blocks (whether initiated through lob
|   call, through direct code block evaluation, or as part of file
|   exportation).  Every time this function is called it will now
|   request confirmation from the user.  The newly added
|   `org-confirm-babel-evaluate' variable can be used to configure this
|   behavior.
| 
| * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block
|   evaluation behavior
| 
| * lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings
|   for executing code blocks and for opening their results
`----

the second commit creates org-babel-load-languages, which can be used to
enable or disable any babel language.

,----[5f5f41a206ccef10b8ff49af8c689995d05da37c]
| babel: `org-babel-load-languages' activates code blocks by language
| 
| * lisp/org.el (org-babel-load-languages): this variable controls which
|   languages will be loaded by org-babel.  It is customizable through
|   the customize interface.
| 
|   (org-babel-do-load-languages): load those languages in
|   org-babel-load-languages and disable those with nil cdr's
`----

While this variable works, and has a very nice customization widget
interface, it is awkward to customize from a user's configuration file,
this is because it relies on the defcustom :set function with which is
it associated, and as far as I can tell, the only way to ensure that the
set function is called, is to set this variable with something along the
lines of the following in your configuration.

--8<---------------cut here---------------start------------->8---
(org-babel-do-load-languages
 'org-babel-load-languages
 '((emacs-lisp . nil)
   (ruby . t)
   (python . nil)
   (R . t)))
--8<---------------cut here---------------end--------------->8---

As of right now I can't think of a more natural way to implement such a
variable -- suggestions welcom :).

As I mentioned I'm keeping this is the babel-safety branch for now, as
it *will* disrupt the configuration and experience of Babel users, and
I've been hard on them already these past few weeks.  Maybe this is best
folded into main along with the version 7.0 release so that it will be
accompanied with web-accessible documentation how to handle the
incomparable changes.

Thanks -- Eric

"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi,
>
> Thanks for finding such a good compromises solution.  This new plan
> looks great to me, specifics below
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Hi everyone,
>>
>> first of all, I think it is clear that I may have overreacted
>> with the "6 point plan".  But it is good that we are having
>> this discussion.
>>
>> On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:
>>
>>> Hi Carsten, Matt, Scott,
>>>
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>
>>>> Hi Matt, hi Eric,
>>>>
>>>> Matt, thanks a lot for bringing this up.  This is indeed a very
>>>> important and serious issue.  We need to address it.  We need to
>>>> step back and reconsider this carefully.
>>>>
>>>> Don't get me wrong, I absolutely think that Org Babel should give
>>>> you enough rope to hang yourself.  But we have to make sure that
>>>> this will not happen to a happy and unsuspecting Org mode, or even
>>>> an unsuspecting Emacs user who by chance opens a file with extension
>>>> .org.
>>>>
>>>> I remember very well when  first realized that shell links could
>>>> really affect you badly.  It scared me.
>>>>
>>>> You main proposal was to make Org Babel an optional module.
>>>> This will not solve the problem fully, I think, because we also
>>>> don't want that people who turn it on automatically commit
>>>> to potentially dangerous operations.  There is a lot of good stuff
>>>> in Babel which has nothing to do with code evaluation.
>>>>
>>>> Here is what I propose (several items are similar to what Eric
>>>> proposes)
>>>>
>>>> 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.
>>
>> Actually, following Dan's argument, I am paddling back on this one.
>> Lets just keep it on.
>>
>> Instead of having a function to unload emacs-lisp, maybe a good way
>> would be a customize option org-babel-load-languages with a checkbox
>> for each language, emacs-lisp on by default.  This would make it easy fo
>> people to select the languages they want, without having to add
>> several require statements to .emacs.
>>
>
> This sounds like a good idea, such a variable would also play the
> important role of advertising what languages currently support execution
> in Babel.  One issue with this setup is that I think languages which do
> not have FSF attribution (currently only oz) would still require an
> explicit `require' statement, however that shouldn't be too surprising
> as those statements live in the contrib directory, and users should be
> used to having to explicitly require functionality located in contrib.
>
> One nice thing about this setup is that it shouldn't break user's
> current config (existing `require' statements will still work).
>
>>
>>>>
>>>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>>>  function
>>>>  This should by default query for confirmation on any org-babel
>>>>  code execution, and can be configured to shut up by people who know
>>>>  what they are doing.
>>>>
>>>
>>> Sounds good, I think this is a reasonable safety measure.
>>>
>>>>
>>>> 3. Not loading emacs lisp evaluation by default.
>>>>
>>>
>>> I would push back on this point.  Largely because we have now crossed
>>> the like to where it is impossible to play with a code block w/o first
>>> dropping down to your configuration files, and evaluating require
>>> statements.
>>>
>>>>
>>>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>>>  for example `C-c C-v e'.  This should be documented as the default
>>>>  key for this operation.
>>>>
>>>
>>> Hmm, I'm less enthusiastic about this point and point 5.  I really
>>> like
>>> how 'C-c C-c' naturally does whatever-I-want given the context in
>>> which
>>> it's called, and I wouldn't want to lose that intuitiveness.
>>> Similarly
>>> 'C-c C-o' currently opens the results of a code block, I also find
>>> this
>>> very appealing as it allows for a uniform top-level interface across
>>> an
>>> Org-mode document, be it a code block or a link.
>>>
>>> Here are my reasons why I think leaving this keybinding is safe.
>>>
>>> 1) Unlike with shell/elisp links, the contents of code blocks is
>>> almost
>>>  always visible right under the user's point.  So it is less likely to
>>>  evaluate something w/o having any idea what you are evaluating.
>>>
>>> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means
>>> that
>>>  the only users who could potentially evaluate a code block with a
>>>  slip of the fingers would be users who have explicitly said that they
>>>  want to be able to easily run code blocks without confirmation.
>>>
>>> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>>>  allows users to run shell commands, C-M-x evaluate the elisp at
>>>  point, and these have not caused problems in the past.
>>
>> These are all very well taken points.  And I agree that a somewhat
>> regular Org-mode user should be protected by this well enough.
>>
>> There are actually two kinds of users and two levels where
>> we need to think about this.
>>
>> 1. I am worried about is this:  Org mode (including Babel)
>> will soon be part of Emacs an be shipped to a very large number of
>> people who have nothing to do with Org mode and might pick a file
>> of the web to try playing with it.  I want to protect these users and
>> also us, as the Org mode community, from a stupid accident happening
>> like that. But, in fact, a yes-or-no-p confirmation would probably
>> cover this well enough. OK for this part.  BTW, Eric,
>> I think this confirmation variable should also be allowed to take
>> a function with a two arguments, the language of the snippet
>> and the snippet.  Users could then write a function which would
>> get confirmation for some snippets, but not for others.
>>
>
> This sounds like a good idea.  I'll update the confirmation function as
> you've described.  One possible issue here is that with complicated
> setups, a single action could require multiple confirmations -- as
> executing one code block can call on other code blocks as arguments, but
> I think that behavior is required to ensure that the user is fully aware
> of the full extent of the processes taking place.
>
>>
>> 2. The other thing is that I am afraid of myself in this context.
>> I envision myself turning off the check eval confirmation check sooner
>> rather than later because I don't like to press the confirmation key
>> all the time.  Repetitive things like this annoy me and I turn them off.
>> So I am happily working with code in a document fine.
>>
>> Later, I see myself accidentally pressing C-c C-c in a place where I did
>> not mean to press it.  Like in Matt's example, this could be a blog post
>> or any other document where I have some source code examples.
>> I press key combinations with C-c *so* many times
>> a day that a couple of `C-c C-c' come up by accident every day.
>> In fact, in this context I am more worried about `C-c C-c' than `C-c
>> C-
>> o'
>> This is why I was proposing to not have this in C-c C-c (and, now
>> you mention it, in C-c C-o) by default.  I definitely think
>> that it would be good to give users a variable to not include
>> these into `C-c C-c' and `C-c C-o'.  Having additional bindings
>> for these two commands in the `C-c C-v' map would not hurt in
>> any case.
>>
>> On the other hand, I totally see how C-c C-c is a great and
>> natural binding if you wan to work with source code, of cause,
>> and I do understand why you defend it and want to have it in by
>> default.
>>
>
> Thanks for your understanding on this point.
>
>>
>> So in summary, I think I could be fine with a situation
>> where the variable I just described exists and is set
>> so that C-c C-c and C-c C-o do the evaluation, and where
>> the issues are clearly documented.
>>
>
> I see your point, and I think your proposed solution is a good
> compromise.  I'll add C-c C-v keybindings for both evaluation and
> opening of code blocks.  Also, I'll add a variable which can be used to
> disable the binding of code block execution to C-c C-c.  We can also
> mention this variable in the documentation for the confirmation
> variable, so that as users disable block confirmation they will
> (hopefully) read the documentation of the variable they are disabling,
> and will stop and think "maybe in a world w/o confirmation, I'd feel
> safer using a higher friction keybinding".
>
> BTW: any suggestions for C-c C-v key bindings, I'm thinking of the
> following, but there may be options with better ergonomics.
> | C-c C-v e | for code block execution, mnemonic "execute" |
> | C-c C-v o | for opening of results, mnemonic "open"      |
>
> Thanks -- Eric
>
>>
>> - Carsten
>>
>>
>>
>>>
>>>>
>>>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>>>  should be optional.
>>>>
>>>> 6. A section in the manual on code execution and associated security
>>>>  risks in Org mode.  This is not only about babel, but also about
>>>>  org-eval, org-eval-light, shell links and elisp links.  I have meant
>>>>  to write this section for a long time and would be willing to
>>>>  draft it. We could then refer to this section from a couple of
>>>>  places in the docs, without cluttering the docs with disclaimers.
>>>>
>>>
>>> This sounds like a very good idea.  I'd be happy to help write such a
>>> section.
>>>
>>>>
>>>> The reason for 4 and 5 is that I believe Org-mode users are trained
>>>> to blindly press `C-c C-c' whenever they want to update something at
>>>> point.  Matt's example of a blog post about `rm -rf' is a very
>>>> realistic example for bad code being evaluated by mistake, not even
>>>> due to malicious cations.  I belive that a special key for this
>>>> action would gove a good measure of protection.
>>>>
>>>
>>> As I mentioned, I personally feel that an org-confirm-babel-eval
>>> variable is sufficient protection.  I think it's safe to assume that
>>> if
>>> a user has explicitly customized that variable, then they know what
>>> they're doing and trust themselves to execute code responsibly.  I
>>> think
>>> it's likely that the casual Org-babel user would never customize this
>>> variable, which seems to me entirely appropriate.
>>>
>>>>
>>>> This is what I think - please let me know if you think I am overdoing
>>>> it.
>>>>
>>>
>>> So to summarize, I think that the combination of (1), (2) and (6),
>>> should be sufficient to protect users from accidental code evaluation.
>>> Please let me know what you think, I am of course looking to
>>> compromise
>>> and I fully understand that the general consensus may be that we need
>>> more layers of protection.
>>>
>>> Best -- Eric
>>>
>>>>
>>>> - Carsten
>>>>
>>>>
>>>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Thanks again for all the work that you, Dan, and Tom have put into
>>>>> org-babel. I'm glad to see it become part of org-mode!
>>>>>
>>>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>>>
>>>>>> 2) Babel will now be loaded by default along with the rest of Org-
>>>>>> mode.
>>>>>> This means that *everyone* currently using babel will need to
>>>>>> change
>>>>>> their Emacs config and remove the (require 'org-babel-int) and/or
>>>>>> (require 'org-babel) lines.
>>>>>
>>>>> I would like to request that org-babel be made an optional module. I
>>>>> ask
>>>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>>>
>>>>> - Org-babel adds rather specific and complex functionality to org-
>>>>> mode
>>>>>  that those who use it as a simple outliner and todo manager do not
>>>>>  require. (In other words, an option to turn it off might be nice
>>>>> for
>>>>>  those who are worried about "feature creep.")
>>>>>
>>>>> - Org-babel increases the risk of accidentally executing malicious
>>>>> or
>>>>>  dangerous code when typing C-c C-c on a src block or exporting a
>>>>>  file. Perhaps users should activate it only after they understand
>>>>>  the risks.
>>>>>
>>>>>  + For instance, I might write a blog post warning about the dangers
>>>>>    of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>>>    and #+end_src and unthinkingly hit C-c C-c, I would be in
>>>>> trouble.
>>>>>    I believe this is the reason for the variables
>>>>>    org-confirm-shell-link-function and
>>>>>    org-confirm-elisp-link-function.
>>>>>
>>>>>  + This is admitted a bit far-fetched as an example, as it would
>>>>>    require one to have loaded ob-sh.el. But since elisp execution is
>>>>>    activated by default, there remain opportunities for unwittingly
>>>>>    executing code that is meant for other purposes (e.g., warnings,
>>>>>    examples, etc.).
>>>>>
>>>>>> Support for evaluating emacs-lisp code blocks is loaded by default.
>>>>>> All other languages will need to be required explicitly.  To
>>>>>> conform
>>>>>> to Emacs filename specifications all language require lines have
>>>>>> been
>>>>>> shortened from e.g.
>>>>>>
>>>>>> (require 'org-babel-sh)
>>>>>>
>>>>>> to
>>>>>>
>>>>>> (require 'ob-sh)
>>>>>
>>>>> When I run make clean && make && make install I find that the
>>>>> language
>>>>> directory is not installed. Does the langs directory require a
>>>>> manual
>>>>> installation?
>>>>>
>>>>> Also, with make install, the ob-* files are installed on the same
>>>>> level
>>>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>>>> should
>>>>> be installed in a babel subdirectory.
>>>>>
>>>>> Thanks!
>>>>> Matt
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> - Carsten
>>>
>>> _______________________________________________
>>> 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
>>
>> - Carsten

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

[Christian Moe]

Hi,

Thanks for getting the safety catch on fast. And thanks to Matt Lundin 
and Carsten Dominik for raising the concerns that were mounting in my 
mind as I caught up with the powers Org-Babel have placed at my 
fingertips. I love knowing it's there, but until I learn to use it, I 
just want to know I won't be causing any mischief with the SRC blocks in 
my humble HOWTO note files.

Yours,
Christian Moe



Eric Schulte wrote:
> Hi,
> 
> Pursuant to the below, I've created a new "babel-safety" branch of the
> repository.  It includes two new commits, the first of which implements
> confirmation before *any* code block evaluation, adds the keybinds for
> code block evaluation, and adds a documentation for disassociating code
> block evaluation from C-c C-c.
> 
> ,----[1d0b2f48c7f4b12b07dcfff0b5c1d29cc2c863bb]
> | babel: evaluation of code blocks now requires confirmation
> | 
> | * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to
> |   control evaluation of code blocks, default value it t, meaning all
> |   code block evaluation requires confirmation
> | 
> |   (org-babel-confirm-evaluate): function used to request confirmation
> |   of code block evaluation from the user
> | 
> |   (org-babel-execute-src-block): this function is the single point of
> |   entry for evaluation of code blocks (whether initiated through lob
> |   call, through direct code block evaluation, or as part of file
> |   exportation).  Every time this function is called it will now
> |   request confirmation from the user.  The newly added
> |   `org-confirm-babel-evaluate' variable can be used to configure this
> |   behavior.
> | 
> | * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block
> |   evaluation behavior
> | 
> | * lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings
> |   for executing code blocks and for opening their results
> `----
> 
> the second commit creates org-babel-load-languages, which can be used to
> enable or disable any babel language.
> 
> ,----[5f5f41a206ccef10b8ff49af8c689995d05da37c]
> | babel: `org-babel-load-languages' activates code blocks by language
> | 
> | * lisp/org.el (org-babel-load-languages): this variable controls which
> |   languages will be loaded by org-babel.  It is customizable through
> |   the customize interface.
> | 
> |   (org-babel-do-load-languages): load those languages in
> |   org-babel-load-languages and disable those with nil cdr's
> `----
> 
> While this variable works, and has a very nice customization widget
> interface, it is awkward to customize from a user's configuration file,
> this is because it relies on the defcustom :set function with which is
> it associated, and as far as I can tell, the only way to ensure that the
> set function is called, is to set this variable with something along the
> lines of the following in your configuration.
> 
> --8<---------------cut here---------------start------------->8---
> (org-babel-do-load-languages
>  'org-babel-load-languages
>  '((emacs-lisp . nil)
>    (ruby . t)
>    (python . nil)
>    (R . t)))
> --8<---------------cut here---------------end--------------->8---
> 
> As of right now I can't think of a more natural way to implement such a
> variable -- suggestions welcom :).
> 
> As I mentioned I'm keeping this is the babel-safety branch for now, as
> it *will* disrupt the configuration and experience of Babel users, and
> I've been hard on them already these past few weeks.  Maybe this is best
> folded into main along with the version 7.0 release so that it will be
> accompanied with web-accessible documentation how to handle the
> incomparable changes.
> 
> Thanks -- Eric
> 
> "Eric Schulte" <schulte.eric@gmail.com> writes:
> 
>> Hi,
>>
>> Thanks for finding such a good compromises solution.  This new plan
>> looks great to me, specifics below
>>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Hi everyone,
>>>
>>> first of all, I think it is clear that I may have overreacted
>>> with the "6 point plan".  But it is good that we are having
>>> this discussion.
>>>
>>> On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:
>>>
>>>> Hi Carsten, Matt, Scott,
>>>>
>>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>>
>>>>> Hi Matt, hi Eric,
>>>>>
>>>>> Matt, thanks a lot for bringing this up.  This is indeed a very
>>>>> important and serious issue.  We need to address it.  We need to
>>>>> step back and reconsider this carefully.
>>>>>
>>>>> Don't get me wrong, I absolutely think that Org Babel should give
>>>>> you enough rope to hang yourself.  But we have to make sure that
>>>>> this will not happen to a happy and unsuspecting Org mode, or even
>>>>> an unsuspecting Emacs user who by chance opens a file with extension
>>>>> .org.
>>>>>
>>>>> I remember very well when  first realized that shell links could
>>>>> really affect you badly.  It scared me.
>>>>>
>>>>> You main proposal was to make Org Babel an optional module.
>>>>> This will not solve the problem fully, I think, because we also
>>>>> don't want that people who turn it on automatically commit
>>>>> to potentially dangerous operations.  There is a lot of good stuff
>>>>> in Babel which has nothing to do with code evaluation.
>>>>>
>>>>> Here is what I propose (several items are similar to what Eric
>>>>> proposes)
>>>>>
>>>>> 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.
>>> Actually, following Dan's argument, I am paddling back on this one.
>>> Lets just keep it on.
>>>
>>> Instead of having a function to unload emacs-lisp, maybe a good way
>>> would be a customize option org-babel-load-languages with a checkbox
>>> for each language, emacs-lisp on by default.  This would make it easy fo
>>> people to select the languages they want, without having to add
>>> several require statements to .emacs.
>>>
>> This sounds like a good idea, such a variable would also play the
>> important role of advertising what languages currently support execution
>> in Babel.  One issue with this setup is that I think languages which do
>> not have FSF attribution (currently only oz) would still require an
>> explicit `require' statement, however that shouldn't be too surprising
>> as those statements live in the contrib directory, and users should be
>> used to having to explicitly require functionality located in contrib.
>>
>> One nice thing about this setup is that it shouldn't break user's
>> current config (existing `require' statements will still work).
>>
>>>>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>>>>  function
>>>>>  This should by default query for confirmation on any org-babel
>>>>>  code execution, and can be configured to shut up by people who know
>>>>>  what they are doing.
>>>>>
>>>> Sounds good, I think this is a reasonable safety measure.
>>>>
>>>>> 3. Not loading emacs lisp evaluation by default.
>>>>>
>>>> I would push back on this point.  Largely because we have now crossed
>>>> the like to where it is impossible to play with a code block w/o first
>>>> dropping down to your configuration files, and evaluating require
>>>> statements.
>>>>
>>>>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>>>>  for example `C-c C-v e'.  This should be documented as the default
>>>>>  key for this operation.
>>>>>
>>>> Hmm, I'm less enthusiastic about this point and point 5.  I really
>>>> like
>>>> how 'C-c C-c' naturally does whatever-I-want given the context in
>>>> which
>>>> it's called, and I wouldn't want to lose that intuitiveness.
>>>> Similarly
>>>> 'C-c C-o' currently opens the results of a code block, I also find
>>>> this
>>>> very appealing as it allows for a uniform top-level interface across
>>>> an
>>>> Org-mode document, be it a code block or a link.
>>>>
>>>> Here are my reasons why I think leaving this keybinding is safe.
>>>>
>>>> 1) Unlike with shell/elisp links, the contents of code blocks is
>>>> almost
>>>>  always visible right under the user's point.  So it is less likely to
>>>>  evaluate something w/o having any idea what you are evaluating.
>>>>
>>>> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means
>>>> that
>>>>  the only users who could potentially evaluate a code block with a
>>>>  slip of the fingers would be users who have explicitly said that they
>>>>  want to be able to easily run code blocks without confirmation.
>>>>
>>>> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>>>>  allows users to run shell commands, C-M-x evaluate the elisp at
>>>>  point, and these have not caused problems in the past.
>>> These are all very well taken points.  And I agree that a somewhat
>>> regular Org-mode user should be protected by this well enough.
>>>
>>> There are actually two kinds of users and two levels where
>>> we need to think about this.
>>>
>>> 1. I am worried about is this:  Org mode (including Babel)
>>> will soon be part of Emacs an be shipped to a very large number of
>>> people who have nothing to do with Org mode and might pick a file
>>> of the web to try playing with it.  I want to protect these users and
>>> also us, as the Org mode community, from a stupid accident happening
>>> like that. But, in fact, a yes-or-no-p confirmation would probably
>>> cover this well enough. OK for this part.  BTW, Eric,
>>> I think this confirmation variable should also be allowed to take
>>> a function with a two arguments, the language of the snippet
>>> and the snippet.  Users could then write a function which would
>>> get confirmation for some snippets, but not for others.
>>>
>> This sounds like a good idea.  I'll update the confirmation function as
>> you've described.  One possible issue here is that with complicated
>> setups, a single action could require multiple confirmations -- as
>> executing one code block can call on other code blocks as arguments, but
>> I think that behavior is required to ensure that the user is fully aware
>> of the full extent of the processes taking place.
>>
>>> 2. The other thing is that I am afraid of myself in this context.
>>> I envision myself turning off the check eval confirmation check sooner
>>> rather than later because I don't like to press the confirmation key
>>> all the time.  Repetitive things like this annoy me and I turn them off.
>>> So I am happily working with code in a document fine.
>>>
>>> Later, I see myself accidentally pressing C-c C-c in a place where I did
>>> not mean to press it.  Like in Matt's example, this could be a blog post
>>> or any other document where I have some source code examples.
>>> I press key combinations with C-c *so* many times
>>> a day that a couple of `C-c C-c' come up by accident every day.
>>> In fact, in this context I am more worried about `C-c C-c' than `C-c
>>> C-
>>> o'
>>> This is why I was proposing to not have this in C-c C-c (and, now
>>> you mention it, in C-c C-o) by default.  I definitely think
>>> that it would be good to give users a variable to not include
>>> these into `C-c C-c' and `C-c C-o'.  Having additional bindings
>>> for these two commands in the `C-c C-v' map would not hurt in
>>> any case.
>>>
>>> On the other hand, I totally see how C-c C-c is a great and
>>> natural binding if you wan to work with source code, of cause,
>>> and I do understand why you defend it and want to have it in by
>>> default.
>>>
>> Thanks for your understanding on this point.
>>
>>> So in summary, I think I could be fine with a situation
>>> where the variable I just described exists and is set
>>> so that C-c C-c and C-c C-o do the evaluation, and where
>>> the issues are clearly documented.
>>>
>> I see your point, and I think your proposed solution is a good
>> compromise.  I'll add C-c C-v keybindings for both evaluation and
>> opening of code blocks.  Also, I'll add a variable which can be used to
>> disable the binding of code block execution to C-c C-c.  We can also
>> mention this variable in the documentation for the confirmation
>> variable, so that as users disable block confirmation they will
>> (hopefully) read the documentation of the variable they are disabling,
>> and will stop and think "maybe in a world w/o confirmation, I'd feel
>> safer using a higher friction keybinding".
>>
>> BTW: any suggestions for C-c C-v key bindings, I'm thinking of the
>> following, but there may be options with better ergonomics.
>> | C-c C-v e | for code block execution, mnemonic "execute" |
>> | C-c C-v o | for opening of results, mnemonic "open"      |
>>
>> Thanks -- Eric
>>
>>> - Carsten
>>>
>>>
>>>
>>>>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>>>>  should be optional.
>>>>>
>>>>> 6. A section in the manual on code execution and associated security
>>>>>  risks in Org mode.  This is not only about babel, but also about
>>>>>  org-eval, org-eval-light, shell links and elisp links.  I have meant
>>>>>  to write this section for a long time and would be willing to
>>>>>  draft it. We could then refer to this section from a couple of
>>>>>  places in the docs, without cluttering the docs with disclaimers.
>>>>>
>>>> This sounds like a very good idea.  I'd be happy to help write such a
>>>> section.
>>>>
>>>>> The reason for 4 and 5 is that I believe Org-mode users are trained
>>>>> to blindly press `C-c C-c' whenever they want to update something at
>>>>> point.  Matt's example of a blog post about `rm -rf' is a very
>>>>> realistic example for bad code being evaluated by mistake, not even
>>>>> due to malicious cations.  I belive that a special key for this
>>>>> action would gove a good measure of protection.
>>>>>
>>>> As I mentioned, I personally feel that an org-confirm-babel-eval
>>>> variable is sufficient protection.  I think it's safe to assume that
>>>> if
>>>> a user has explicitly customized that variable, then they know what
>>>> they're doing and trust themselves to execute code responsibly.  I
>>>> think
>>>> it's likely that the casual Org-babel user would never customize this
>>>> variable, which seems to me entirely appropriate.
>>>>
>>>>> This is what I think - please let me know if you think I am overdoing
>>>>> it.
>>>>>
>>>> So to summarize, I think that the combination of (1), (2) and (6),
>>>> should be sufficient to protect users from accidental code evaluation.
>>>> Please let me know what you think, I am of course looking to
>>>> compromise
>>>> and I fully understand that the general consensus may be that we need
>>>> more layers of protection.
>>>>
>>>> Best -- Eric
>>>>
>>>>> - Carsten
>>>>>
>>>>>
>>>>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>> Thanks again for all the work that you, Dan, and Tom have put into
>>>>>> org-babel. I'm glad to see it become part of org-mode!
>>>>>>
>>>>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>>>>
>>>>>>> 2) Babel will now be loaded by default along with the rest of Org-
>>>>>>> mode.
>>>>>>> This means that *everyone* currently using babel will need to
>>>>>>> change
>>>>>>> their Emacs config and remove the (require 'org-babel-int) and/or
>>>>>>> (require 'org-babel) lines.
>>>>>> I would like to request that org-babel be made an optional module. I
>>>>>> ask
>>>>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>>>>
>>>>>> - Org-babel adds rather specific and complex functionality to org-
>>>>>> mode
>>>>>>  that those who use it as a simple outliner and todo manager do not
>>>>>>  require. (In other words, an option to turn it off might be nice
>>>>>> for
>>>>>>  those who are worried about "feature creep.")
>>>>>>
>>>>>> - Org-babel increases the risk of accidentally executing malicious
>>>>>> or
>>>>>>  dangerous code when typing C-c C-c on a src block or exporting a
>>>>>>  file. Perhaps users should activate it only after they understand
>>>>>>  the risks.
>>>>>>
>>>>>>  + For instance, I might write a blog post warning about the dangers
>>>>>>    of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>>>>    and #+end_src and unthinkingly hit C-c C-c, I would be in
>>>>>> trouble.
>>>>>>    I believe this is the reason for the variables
>>>>>>    org-confirm-shell-link-function and
>>>>>>    org-confirm-elisp-link-function.
>>>>>>
>>>>>>  + This is admitted a bit far-fetched as an example, as it would
>>>>>>    require one to have loaded ob-sh.el. But since elisp execution is
>>>>>>    activated by default, there remain opportunities for unwittingly
>>>>>>    executing code that is meant for other purposes (e.g., warnings,
>>>>>>    examples, etc.).
>>>>>>
>>>>>>> Support for evaluating emacs-lisp code blocks is loaded by default.
>>>>>>> All other languages will need to be required explicitly.  To
>>>>>>> conform
>>>>>>> to Emacs filename specifications all language require lines have
>>>>>>> been
>>>>>>> shortened from e.g.
>>>>>>>
>>>>>>> (require 'org-babel-sh)
>>>>>>>
>>>>>>> to
>>>>>>>
>>>>>>> (require 'ob-sh)
>>>>>> When I run make clean && make && make install I find that the
>>>>>> language
>>>>>> directory is not installed. Does the langs directory require a
>>>>>> manual
>>>>>> installation?
>>>>>>
>>>>>> Also, with make install, the ob-* files are installed on the same
>>>>>> level
>>>>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>>>>> should
>>>>>> be installed in a babel subdirectory.
>>>>>>
>>>>>> Thanks!
>>>>>> Matt
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>> - Carsten
>>>> _______________________________________________
>>>> 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
>>> - Carsten
> 
> _______________________________________________
> 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
> 


-- 

Christian Moe
E-mail:  mail@christianmoe.com
Website: http://christianmoe.com

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

[Nick Dokos]

Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> wrote:

> Nick Dokos wrote:
> > Carsten Dominik <carsten.dominik@gmail.com> wrote:
> >> 
> >> :-) Actually, in this specific area I had been thinking to removing or at
> >> least deprecating shell and elisp links, because the Org-babel way is much
> >> better and clearer to have that code in a block, rather than hiding it in
> >> the invisible part of of a link.
> >
> > Here is an early vote [1] for *not* removing shell and elisp links.
> > Deprecation/documentation/scary warnings is fine with me, but I do use these
> > kinds of links and I'd like to be able to continue using them.
> 
> For my own understanding of what more I could do that I don't even think of
> right now, *if not indiscreet/private*, could you give a couple of
> applications of such links?
> 

Hi Seb,

it's nothing spectacular: on the contrary, it's all the mundane things
that I have various scripts for (either shell or elisp), e.g. munge with
my jottings of the week and prepare a weekly report that is mailed to my
manager and also exported to HTML for posterity - that's an elisp
link. It's particularly things that I don't do often enough so I tend
to forget what they are called, what arguments they take, etc.

The links provide just enough documentation to jog my memory and a
convenient way to launch the thing. I have a lot of these in many files:
they tend to be very specific and so after a while the details slip away
(e.g. the org file that describes all I know about a particular bug,
might have a link to the bugzilla entry for the bug (an html link),
email links, file links to data and a link to start a test run - this
last is generally a shell link).

Before org, for shell scripts, I would list my ~/bin directory and try
to discern which of the many hundreds of scripts in there is the one
that I need, and assuming that I would find it, I would then read the
script to find what arguments it would need. Now, I visit an org file
(one of a handful, organized by topic), read the link description and
activate it.

IOW, it could all be done in org-babel, but I started these a long time
ago and I have accumulated so many of them, that converting would be a
pain. In addition, they are spread out all over the place, so I would
have to convert them one by one as I need them and there are so many
possible places for Murphy's law to intrude, that losing the capability
would be cause for serious concern for me. Hence the preemptive vote :-)

Cheers,
Nick

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

[Carsten Dominik]

Hi Eric, thanks for this.

I would actually like to have a variable that will exclude evaluation
from being added to the C-c C-c hook.  I think users will understand  
better
how to use this, and customizing it will work for sure.  Explicitly
removing it from the hook will only work after load time.

We should also add

(put 'org-confirm-babel-evaluate
      'safe-local-variable
      (lambda (x) (eq x t)))

After the definition of org-confirm-babel-evaluate to avoid that
malicious code can change this setting through file variables.

I have made a first draft of the security section in the manual,
please take a look, add to it, and add a link to it from a good location
in chapter 14.

Cheers

- Carsten

On Jul 1, 2010, at 10:39 PM, Eric Schulte wrote:

> Hi,
>
> Pursuant to the below, I've created a new "babel-safety" branch of the
> repository.  It includes two new commits, the first of which  
> implements
> confirmation before *any* code block evaluation, adds the keybinds for
> code block evaluation, and adds a documentation for disassociating  
> code
> block evaluation from C-c C-c.
>
> ,----[1d0b2f48c7f4b12b07dcfff0b5c1d29cc2c863bb]
> | babel: evaluation of code blocks now requires confirmation
> |
> | * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to
> |   control evaluation of code blocks, default value it t, meaning all
> |   code block evaluation requires confirmation
> |
> |   (org-babel-confirm-evaluate): function used to request  
> confirmation
> |   of code block evaluation from the user
> |
> |   (org-babel-execute-src-block): this function is the single point  
> of
> |   entry for evaluation of code blocks (whether initiated through lob
> |   call, through direct code block evaluation, or as part of file
> |   exportation).  Every time this function is called it will now
> |   request confirmation from the user.  The newly added
> |   `org-confirm-babel-evaluate' variable can be used to configure  
> this
> |   behavior.
> |
> | * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block
> |   evaluation behavior
> |
> | * lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings
> |   for executing code blocks and for opening their results
> `----
>
> the second commit creates org-babel-load-languages, which can be  
> used to
> enable or disable any babel language.
>
> ,----[5f5f41a206ccef10b8ff49af8c689995d05da37c]
> | babel: `org-babel-load-languages' activates code blocks by language
> |
> | * lisp/org.el (org-babel-load-languages): this variable controls  
> which
> |   languages will be loaded by org-babel.  It is customizable through
> |   the customize interface.
> |
> |   (org-babel-do-load-languages): load those languages in
> |   org-babel-load-languages and disable those with nil cdr's
> `----
>
> While this variable works, and has a very nice customization widget
> interface, it is awkward to customize from a user's configuration  
> file,
> this is because it relies on the defcustom :set function with which is
> it associated, and as far as I can tell, the only way to ensure that  
> the
> set function is called, is to set this variable with something along  
> the
> lines of the following in your configuration.
>
> --8<---------------cut here---------------start------------->8---
> (org-babel-do-load-languages
> 'org-babel-load-languages
> '((emacs-lisp . nil)
>   (ruby . t)
>   (python . nil)
>   (R . t)))
> --8<---------------cut here---------------end--------------->8---
>
> As of right now I can't think of a more natural way to implement  
> such a
> variable -- suggestions welcom :).
>
> As I mentioned I'm keeping this is the babel-safety branch for now, as
> it *will* disrupt the configuration and experience of Babel users, and
> I've been hard on them already these past few weeks.  Maybe this is  
> best
> folded into main along with the version 7.0 release so that it will be
> accompanied with web-accessible documentation how to handle the
> incomparable changes.
>
> Thanks -- Eric
>
> "Eric Schulte" <schulte.eric@gmail.com> writes:
>
>> Hi,
>>
>> Thanks for finding such a good compromises solution.  This new plan
>> looks great to me, specifics below
>>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> Hi everyone,
>>>
>>> first of all, I think it is clear that I may have overreacted
>>> with the "6 point plan".  But it is good that we are having
>>> this discussion.
>>>
>>> On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:
>>>
>>>> Hi Carsten, Matt, Scott,
>>>>
>>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>>
>>>>> Hi Matt, hi Eric,
>>>>>
>>>>> Matt, thanks a lot for bringing this up.  This is indeed a very
>>>>> important and serious issue.  We need to address it.  We need to
>>>>> step back and reconsider this carefully.
>>>>>
>>>>> Don't get me wrong, I absolutely think that Org Babel should give
>>>>> you enough rope to hang yourself.  But we have to make sure that
>>>>> this will not happen to a happy and unsuspecting Org mode, or even
>>>>> an unsuspecting Emacs user who by chance opens a file with  
>>>>> extension
>>>>> .org.
>>>>>
>>>>> I remember very well when  first realized that shell links could
>>>>> really affect you badly.  It scared me.
>>>>>
>>>>> You main proposal was to make Org Babel an optional module.
>>>>> This will not solve the problem fully, I think, because we also
>>>>> don't want that people who turn it on automatically commit
>>>>> to potentially dangerous operations.  There is a lot of good stuff
>>>>> in Babel which has nothing to do with code evaluation.
>>>>>
>>>>> Here is what I propose (several items are similar to what Eric
>>>>> proposes)
>>>>>
>>>>> 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.
>>>
>>> Actually, following Dan's argument, I am paddling back on this one.
>>> Lets just keep it on.
>>>
>>> Instead of having a function to unload emacs-lisp, maybe a good way
>>> would be a customize option org-babel-load-languages with a checkbox
>>> for each language, emacs-lisp on by default.  This would make it  
>>> easy fo
>>> people to select the languages they want, without having to add
>>> several require statements to .emacs.
>>>
>>
>> This sounds like a good idea, such a variable would also play the
>> important role of advertising what languages currently support  
>> execution
>> in Babel.  One issue with this setup is that I think languages  
>> which do
>> not have FSF attribution (currently only oz) would still require an
>> explicit `require' statement, however that shouldn't be too  
>> surprising
>> as those statements live in the contrib directory, and users should  
>> be
>> used to having to explicitly require functionality located in  
>> contrib.
>>
>> One nice thing about this setup is that it shouldn't break user's
>> current config (existing `require' statements will still work).
>>
>>>
>>>>>
>>>>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>>>> function
>>>>> This should by default query for confirmation on any org-babel
>>>>> code execution, and can be configured to shut up by people who  
>>>>> know
>>>>> what they are doing.
>>>>>
>>>>
>>>> Sounds good, I think this is a reasonable safety measure.
>>>>
>>>>>
>>>>> 3. Not loading emacs lisp evaluation by default.
>>>>>
>>>>
>>>> I would push back on this point.  Largely because we have now  
>>>> crossed
>>>> the like to where it is impossible to play with a code block w/o  
>>>> first
>>>> dropping down to your configuration files, and evaluating require
>>>> statements.
>>>>
>>>>>
>>>>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>>>> for example `C-c C-v e'.  This should be documented as the default
>>>>> key for this operation.
>>>>>
>>>>
>>>> Hmm, I'm less enthusiastic about this point and point 5.  I really
>>>> like
>>>> how 'C-c C-c' naturally does whatever-I-want given the context in
>>>> which
>>>> it's called, and I wouldn't want to lose that intuitiveness.
>>>> Similarly
>>>> 'C-c C-o' currently opens the results of a code block, I also find
>>>> this
>>>> very appealing as it allows for a uniform top-level interface  
>>>> across
>>>> an
>>>> Org-mode document, be it a code block or a link.
>>>>
>>>> Here are my reasons why I think leaving this keybinding is safe.
>>>>
>>>> 1) Unlike with shell/elisp links, the contents of code blocks is
>>>> almost
>>>> always visible right under the user's point.  So it is less  
>>>> likely to
>>>> evaluate something w/o having any idea what you are evaluating.
>>>>
>>>> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means
>>>> that
>>>> the only users who could potentially evaluate a code block with a
>>>> slip of the fingers would be users who have explicitly said that  
>>>> they
>>>> want to be able to easily run code blocks without confirmation.
>>>>
>>>> 3) Emacs exposes a number of entry points into code evaluation.   
>>>> M-!
>>>> allows users to run shell commands, C-M-x evaluate the elisp at
>>>> point, and these have not caused problems in the past.
>>>
>>> These are all very well taken points.  And I agree that a somewhat
>>> regular Org-mode user should be protected by this well enough.
>>>
>>> There are actually two kinds of users and two levels where
>>> we need to think about this.
>>>
>>> 1. I am worried about is this:  Org mode (including Babel)
>>> will soon be part of Emacs an be shipped to a very large number of
>>> people who have nothing to do with Org mode and might pick a file
>>> of the web to try playing with it.  I want to protect these users  
>>> and
>>> also us, as the Org mode community, from a stupid accident happening
>>> like that. But, in fact, a yes-or-no-p confirmation would probably
>>> cover this well enough. OK for this part.  BTW, Eric,
>>> I think this confirmation variable should also be allowed to take
>>> a function with a two arguments, the language of the snippet
>>> and the snippet.  Users could then write a function which would
>>> get confirmation for some snippets, but not for others.
>>>
>>
>> This sounds like a good idea.  I'll update the confirmation  
>> function as
>> you've described.  One possible issue here is that with complicated
>> setups, a single action could require multiple confirmations -- as
>> executing one code block can call on other code blocks as  
>> arguments, but
>> I think that behavior is required to ensure that the user is fully  
>> aware
>> of the full extent of the processes taking place.
>>
>>>
>>> 2. The other thing is that I am afraid of myself in this context.
>>> I envision myself turning off the check eval confirmation check  
>>> sooner
>>> rather than later because I don't like to press the confirmation key
>>> all the time.  Repetitive things like this annoy me and I turn  
>>> them off.
>>> So I am happily working with code in a document fine.
>>>
>>> Later, I see myself accidentally pressing C-c C-c in a place where  
>>> I did
>>> not mean to press it.  Like in Matt's example, this could be a  
>>> blog post
>>> or any other document where I have some source code examples.
>>> I press key combinations with C-c *so* many times
>>> a day that a couple of `C-c C-c' come up by accident every day.
>>> In fact, in this context I am more worried about `C-c C-c' than `C-c
>>> C-
>>> o'
>>> This is why I was proposing to not have this in C-c C-c (and, now
>>> you mention it, in C-c C-o) by default.  I definitely think
>>> that it would be good to give users a variable to not include
>>> these into `C-c C-c' and `C-c C-o'.  Having additional bindings
>>> for these two commands in the `C-c C-v' map would not hurt in
>>> any case.
>>>
>>> On the other hand, I totally see how C-c C-c is a great and
>>> natural binding if you wan to work with source code, of cause,
>>> and I do understand why you defend it and want to have it in by
>>> default.
>>>
>>
>> Thanks for your understanding on this point.
>>
>>>
>>> So in summary, I think I could be fine with a situation
>>> where the variable I just described exists and is set
>>> so that C-c C-c and C-c C-o do the evaluation, and where
>>> the issues are clearly documented.
>>>
>>
>> I see your point, and I think your proposed solution is a good
>> compromise.  I'll add C-c C-v keybindings for both evaluation and
>> opening of code blocks.  Also, I'll add a variable which can be  
>> used to
>> disable the binding of code block execution to C-c C-c.  We can also
>> mention this variable in the documentation for the confirmation
>> variable, so that as users disable block confirmation they will
>> (hopefully) read the documentation of the variable they are  
>> disabling,
>> and will stop and think "maybe in a world w/o confirmation, I'd feel
>> safer using a higher friction keybinding".
>>
>> BTW: any suggestions for C-c C-v key bindings, I'm thinking of the
>> following, but there may be options with better ergonomics.
>> | C-c C-v e | for code block execution, mnemonic "execute" |
>> | C-c C-v o | for opening of results, mnemonic "open"      |
>>
>> Thanks -- Eric
>>
>>>
>>> - Carsten
>>>
>>>
>>>
>>>>
>>>>>
>>>>> 5. Removing org-babel-execute-code-block from `C-c C-c'.   
>>>>> Inclusion
>>>>> should be optional.
>>>>>
>>>>> 6. A section in the manual on code execution and associated  
>>>>> security
>>>>> risks in Org mode.  This is not only about babel, but also about
>>>>> org-eval, org-eval-light, shell links and elisp links.  I have  
>>>>> meant
>>>>> to write this section for a long time and would be willing to
>>>>> draft it. We could then refer to this section from a couple of
>>>>> places in the docs, without cluttering the docs with disclaimers.
>>>>>
>>>>
>>>> This sounds like a very good idea.  I'd be happy to help write  
>>>> such a
>>>> section.
>>>>
>>>>>
>>>>> The reason for 4 and 5 is that I believe Org-mode users are  
>>>>> trained
>>>>> to blindly press `C-c C-c' whenever they want to update  
>>>>> something at
>>>>> point.  Matt's example of a blog post about `rm -rf' is a very
>>>>> realistic example for bad code being evaluated by mistake, not  
>>>>> even
>>>>> due to malicious cations.  I belive that a special key for this
>>>>> action would gove a good measure of protection.
>>>>>
>>>>
>>>> As I mentioned, I personally feel that an org-confirm-babel-eval
>>>> variable is sufficient protection.  I think it's safe to assume  
>>>> that
>>>> if
>>>> a user has explicitly customized that variable, then they know what
>>>> they're doing and trust themselves to execute code responsibly.  I
>>>> think
>>>> it's likely that the casual Org-babel user would never customize  
>>>> this
>>>> variable, which seems to me entirely appropriate.
>>>>
>>>>>
>>>>> This is what I think - please let me know if you think I am  
>>>>> overdoing
>>>>> it.
>>>>>
>>>>
>>>> So to summarize, I think that the combination of (1), (2) and (6),
>>>> should be sufficient to protect users from accidental code  
>>>> evaluation.
>>>> Please let me know what you think, I am of course looking to
>>>> compromise
>>>> and I fully understand that the general consensus may be that we  
>>>> need
>>>> more layers of protection.
>>>>
>>>> Best -- Eric
>>>>
>>>>>
>>>>> - Carsten
>>>>>
>>>>>
>>>>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>> Thanks again for all the work that you, Dan, and Tom have put  
>>>>>> into
>>>>>> org-babel. I'm glad to see it become part of org-mode!
>>>>>>
>>>>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>>>>
>>>>>>> 2) Babel will now be loaded by default along with the rest of  
>>>>>>> Org-
>>>>>>> mode.
>>>>>>> This means that *everyone* currently using babel will need to
>>>>>>> change
>>>>>>> their Emacs config and remove the (require 'org-babel-int) and/ 
>>>>>>> or
>>>>>>> (require 'org-babel) lines.
>>>>>>
>>>>>> I would like to request that org-babel be made an optional  
>>>>>> module. I
>>>>>> ask
>>>>>> this as someone who uses org-babel regularly. Here are my  
>>>>>> reasons:
>>>>>>
>>>>>> - Org-babel adds rather specific and complex functionality to  
>>>>>> org-
>>>>>> mode
>>>>>> that those who use it as a simple outliner and todo manager do  
>>>>>> not
>>>>>> require. (In other words, an option to turn it off might be nice
>>>>>> for
>>>>>> those who are worried about "feature creep.")
>>>>>>
>>>>>> - Org-babel increases the risk of accidentally executing  
>>>>>> malicious
>>>>>> or
>>>>>> dangerous code when typing C-c C-c on a src block or exporting a
>>>>>> file. Perhaps users should activate it only after they understand
>>>>>> the risks.
>>>>>>
>>>>>> + For instance, I might write a blog post warning about the  
>>>>>> dangers
>>>>>>   of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>>>>   and #+end_src and unthinkingly hit C-c C-c, I would be in
>>>>>> trouble.
>>>>>>   I believe this is the reason for the variables
>>>>>>   org-confirm-shell-link-function and
>>>>>>   org-confirm-elisp-link-function.
>>>>>>
>>>>>> + This is admitted a bit far-fetched as an example, as it would
>>>>>>   require one to have loaded ob-sh.el. But since elisp  
>>>>>> execution is
>>>>>>   activated by default, there remain opportunities for  
>>>>>> unwittingly
>>>>>>   executing code that is meant for other purposes (e.g.,  
>>>>>> warnings,
>>>>>>   examples, etc.).
>>>>>>
>>>>>>> Support for evaluating emacs-lisp code blocks is loaded by  
>>>>>>> default.
>>>>>>> All other languages will need to be required explicitly.  To
>>>>>>> conform
>>>>>>> to Emacs filename specifications all language require lines have
>>>>>>> been
>>>>>>> shortened from e.g.
>>>>>>>
>>>>>>> (require 'org-babel-sh)
>>>>>>>
>>>>>>> to
>>>>>>>
>>>>>>> (require 'ob-sh)
>>>>>>
>>>>>> When I run make clean && make && make install I find that the
>>>>>> language
>>>>>> directory is not installed. Does the langs directory require a
>>>>>> manual
>>>>>> installation?
>>>>>>
>>>>>> Also, with make install, the ob-* files are installed on the same
>>>>>> level
>>>>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>>>>> should
>>>>>> be installed in a babel subdirectory.
>>>>>>
>>>>>> Thanks!
>>>>>> Matt
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> - Carsten
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> - Carsten

- Carsten

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

[Carsten Dominik]

Hi Eric,

thanks, I think we have a good solution, at least for the time being.

I have started the security section in the manual, please feel free to  
add to it.

- Carsten

On Jul 1, 2010, at 4:55 PM, Eric Schulte wrote:

> Hi,
>
> Thanks for finding such a good compromises solution.  This new plan
> looks great to me, specifics below
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> Hi everyone,
>>
>> first of all, I think it is clear that I may have overreacted
>> with the "6 point plan".  But it is good that we are having
>> this discussion.
>>
>> On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:
>>
>>> Hi Carsten, Matt, Scott,
>>>
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>
>>>> Hi Matt, hi Eric,
>>>>
>>>> Matt, thanks a lot for bringing this up.  This is indeed a very
>>>> important and serious issue.  We need to address it.  We need to
>>>> step back and reconsider this carefully.
>>>>
>>>> Don't get me wrong, I absolutely think that Org Babel should give
>>>> you enough rope to hang yourself.  But we have to make sure that
>>>> this will not happen to a happy and unsuspecting Org mode, or even
>>>> an unsuspecting Emacs user who by chance opens a file with  
>>>> extension
>>>> .org.
>>>>
>>>> I remember very well when  first realized that shell links could
>>>> really affect you badly.  It scared me.
>>>>
>>>> You main proposal was to make Org Babel an optional module.
>>>> This will not solve the problem fully, I think, because we also
>>>> don't want that people who turn it on automatically commit
>>>> to potentially dangerous operations.  There is a lot of good stuff
>>>> in Babel which has nothing to do with code evaluation.
>>>>
>>>> Here is what I propose (several items are similar to what Eric
>>>> proposes)
>>>>
>>>> 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.
>>
>> Actually, following Dan's argument, I am paddling back on this one.
>> Lets just keep it on.
>>
>> Instead of having a function to unload emacs-lisp, maybe a good way
>> would be a customize option org-babel-load-languages with a checkbox
>> for each language, emacs-lisp on by default.  This would make it  
>> easy fo
>> people to select the languages they want, without having to add
>> several require statements to .emacs.
>>
>
> This sounds like a good idea, such a variable would also play the
> important role of advertising what languages currently support  
> execution
> in Babel.  One issue with this setup is that I think languages which  
> do
> not have FSF attribution (currently only oz) would still require an
> explicit `require' statement, however that shouldn't be too surprising
> as those statements live in the contrib directory, and users should be
> used to having to explicitly require functionality located in contrib.
>
> One nice thing about this setup is that it shouldn't break user's
> current config (existing `require' statements will still work).
>
>>
>>>>
>>>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>>> function
>>>> This should by default query for confirmation on any org-babel
>>>> code execution, and can be configured to shut up by people who know
>>>> what they are doing.
>>>>
>>>
>>> Sounds good, I think this is a reasonable safety measure.
>>>
>>>>
>>>> 3. Not loading emacs lisp evaluation by default.
>>>>
>>>
>>> I would push back on this point.  Largely because we have now  
>>> crossed
>>> the like to where it is impossible to play with a code block w/o  
>>> first
>>> dropping down to your configuration files, and evaluating require
>>> statements.
>>>
>>>>
>>>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>>> for example `C-c C-v e'.  This should be documented as the default
>>>> key for this operation.
>>>>
>>>
>>> Hmm, I'm less enthusiastic about this point and point 5.  I really
>>> like
>>> how 'C-c C-c' naturally does whatever-I-want given the context in
>>> which
>>> it's called, and I wouldn't want to lose that intuitiveness.
>>> Similarly
>>> 'C-c C-o' currently opens the results of a code block, I also find
>>> this
>>> very appealing as it allows for a uniform top-level interface across
>>> an
>>> Org-mode document, be it a code block or a link.
>>>
>>> Here are my reasons why I think leaving this keybinding is safe.
>>>
>>> 1) Unlike with shell/elisp links, the contents of code blocks is
>>> almost
>>> always visible right under the user's point.  So it is less likely  
>>> to
>>> evaluate something w/o having any idea what you are evaluating.
>>>
>>> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means
>>> that
>>> the only users who could potentially evaluate a code block with a
>>> slip of the fingers would be users who have explicitly said that  
>>> they
>>> want to be able to easily run code blocks without confirmation.
>>>
>>> 3) Emacs exposes a number of entry points into code evaluation.  M-!
>>> allows users to run shell commands, C-M-x evaluate the elisp at
>>> point, and these have not caused problems in the past.
>>
>> These are all very well taken points.  And I agree that a somewhat
>> regular Org-mode user should be protected by this well enough.
>>
>> There are actually two kinds of users and two levels where
>> we need to think about this.
>>
>> 1. I am worried about is this:  Org mode (including Babel)
>> will soon be part of Emacs an be shipped to a very large number of
>> people who have nothing to do with Org mode and might pick a file
>> of the web to try playing with it.  I want to protect these users and
>> also us, as the Org mode community, from a stupid accident happening
>> like that. But, in fact, a yes-or-no-p confirmation would probably
>> cover this well enough. OK for this part.  BTW, Eric,
>> I think this confirmation variable should also be allowed to take
>> a function with a two arguments, the language of the snippet
>> and the snippet.  Users could then write a function which would
>> get confirmation for some snippets, but not for others.
>>
>
> This sounds like a good idea.  I'll update the confirmation function  
> as
> you've described.  One possible issue here is that with complicated
> setups, a single action could require multiple confirmations -- as
> executing one code block can call on other code blocks as arguments,  
> but
> I think that behavior is required to ensure that the user is fully  
> aware
> of the full extent of the processes taking place.
>
>>
>> 2. The other thing is that I am afraid of myself in this context.
>> I envision myself turning off the check eval confirmation check  
>> sooner
>> rather than later because I don't like to press the confirmation key
>> all the time.  Repetitive things like this annoy me and I turn them  
>> off.
>> So I am happily working with code in a document fine.
>>
>> Later, I see myself accidentally pressing C-c C-c in a place where  
>> I did
>> not mean to press it.  Like in Matt's example, this could be a blog  
>> post
>> or any other document where I have some source code examples.
>> I press key combinations with C-c *so* many times
>> a day that a couple of `C-c C-c' come up by accident every day.
>> In fact, in this context I am more worried about `C-c C-c' than `C-c
>> C-
>> o'
>> This is why I was proposing to not have this in C-c C-c (and, now
>> you mention it, in C-c C-o) by default.  I definitely think
>> that it would be good to give users a variable to not include
>> these into `C-c C-c' and `C-c C-o'.  Having additional bindings
>> for these two commands in the `C-c C-v' map would not hurt in
>> any case.
>>
>> On the other hand, I totally see how C-c C-c is a great and
>> natural binding if you wan to work with source code, of cause,
>> and I do understand why you defend it and want to have it in by
>> default.
>>
>
> Thanks for your understanding on this point.
>
>>
>> So in summary, I think I could be fine with a situation
>> where the variable I just described exists and is set
>> so that C-c C-c and C-c C-o do the evaluation, and where
>> the issues are clearly documented.
>>
>
> I see your point, and I think your proposed solution is a good
> compromise.  I'll add C-c C-v keybindings for both evaluation and
> opening of code blocks.  Also, I'll add a variable which can be used  
> to
> disable the binding of code block execution to C-c C-c.  We can also
> mention this variable in the documentation for the confirmation
> variable, so that as users disable block confirmation they will
> (hopefully) read the documentation of the variable they are disabling,
> and will stop and think "maybe in a world w/o confirmation, I'd feel
> safer using a higher friction keybinding".
>
> BTW: any suggestions for C-c C-v key bindings, I'm thinking of the
> following, but there may be options with better ergonomics.
> | C-c C-v e | for code block execution, mnemonic "execute" |
> | C-c C-v o | for opening of results, mnemonic "open"      |
>
> Thanks -- Eric
>
>>
>> - Carsten
>>
>>
>>
>>>
>>>>
>>>> 5. Removing org-babel-execute-code-block from `C-c C-c'.  Inclusion
>>>> should be optional.
>>>>
>>>> 6. A section in the manual on code execution and associated  
>>>> security
>>>> risks in Org mode.  This is not only about babel, but also about
>>>> org-eval, org-eval-light, shell links and elisp links.  I have  
>>>> meant
>>>> to write this section for a long time and would be willing to
>>>> draft it. We could then refer to this section from a couple of
>>>> places in the docs, without cluttering the docs with disclaimers.
>>>>
>>>
>>> This sounds like a very good idea.  I'd be happy to help write  
>>> such a
>>> section.
>>>
>>>>
>>>> The reason for 4 and 5 is that I believe Org-mode users are trained
>>>> to blindly press `C-c C-c' whenever they want to update something  
>>>> at
>>>> point.  Matt's example of a blog post about `rm -rf' is a very
>>>> realistic example for bad code being evaluated by mistake, not even
>>>> due to malicious cations.  I belive that a special key for this
>>>> action would gove a good measure of protection.
>>>>
>>>
>>> As I mentioned, I personally feel that an org-confirm-babel-eval
>>> variable is sufficient protection.  I think it's safe to assume that
>>> if
>>> a user has explicitly customized that variable, then they know what
>>> they're doing and trust themselves to execute code responsibly.  I
>>> think
>>> it's likely that the casual Org-babel user would never customize  
>>> this
>>> variable, which seems to me entirely appropriate.
>>>
>>>>
>>>> This is what I think - please let me know if you think I am  
>>>> overdoing
>>>> it.
>>>>
>>>
>>> So to summarize, I think that the combination of (1), (2) and (6),
>>> should be sufficient to protect users from accidental code  
>>> evaluation.
>>> Please let me know what you think, I am of course looking to
>>> compromise
>>> and I fully understand that the general consensus may be that we  
>>> need
>>> more layers of protection.
>>>
>>> Best -- Eric
>>>
>>>>
>>>> - Carsten
>>>>
>>>>
>>>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Thanks again for all the work that you, Dan, and Tom have put into
>>>>> org-babel. I'm glad to see it become part of org-mode!
>>>>>
>>>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>>>
>>>>>> 2) Babel will now be loaded by default along with the rest of  
>>>>>> Org-
>>>>>> mode.
>>>>>> This means that *everyone* currently using babel will need to
>>>>>> change
>>>>>> their Emacs config and remove the (require 'org-babel-int) and/or
>>>>>> (require 'org-babel) lines.
>>>>>
>>>>> I would like to request that org-babel be made an optional  
>>>>> module. I
>>>>> ask
>>>>> this as someone who uses org-babel regularly. Here are my reasons:
>>>>>
>>>>> - Org-babel adds rather specific and complex functionality to org-
>>>>> mode
>>>>> that those who use it as a simple outliner and todo manager do not
>>>>> require. (In other words, an option to turn it off might be nice
>>>>> for
>>>>> those who are worried about "feature creep.")
>>>>>
>>>>> - Org-babel increases the risk of accidentally executing malicious
>>>>> or
>>>>> dangerous code when typing C-c C-c on a src block or exporting a
>>>>> file. Perhaps users should activate it only after they understand
>>>>> the risks.
>>>>>
>>>>> + For instance, I might write a blog post warning about the  
>>>>> dangers
>>>>>  of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>>>  and #+end_src and unthinkingly hit C-c C-c, I would be in
>>>>> trouble.
>>>>>  I believe this is the reason for the variables
>>>>>  org-confirm-shell-link-function and
>>>>>  org-confirm-elisp-link-function.
>>>>>
>>>>> + This is admitted a bit far-fetched as an example, as it would
>>>>>  require one to have loaded ob-sh.el. But since elisp execution is
>>>>>  activated by default, there remain opportunities for unwittingly
>>>>>  executing code that is meant for other purposes (e.g., warnings,
>>>>>  examples, etc.).
>>>>>
>>>>>> Support for evaluating emacs-lisp code blocks is loaded by  
>>>>>> default.
>>>>>> All other languages will need to be required explicitly.  To
>>>>>> conform
>>>>>> to Emacs filename specifications all language require lines have
>>>>>> been
>>>>>> shortened from e.g.
>>>>>>
>>>>>> (require 'org-babel-sh)
>>>>>>
>>>>>> to
>>>>>>
>>>>>> (require 'ob-sh)
>>>>>
>>>>> When I run make clean && make && make install I find that the
>>>>> language
>>>>> directory is not installed. Does the langs directory require a
>>>>> manual
>>>>> installation?
>>>>>
>>>>> Also, with make install, the ob-* files are installed on the same
>>>>> level
>>>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>>>> should
>>>>> be installed in a babel subdirectory.
>>>>>
>>>>> Thanks!
>>>>> Matt
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> - Carsten
>>>
>>> _______________________________________________
>>> 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
>>
>> - Carsten

- Carsten

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

[Christopher Witte]

Eric,

Thanks, it all appears to be working now.

Cheers,
Chris.

On 28 June 2010 18:59, Eric Schulte <schulte.eric@gmail.com> wrote:
> Hi Christopher,
>
> Christopher Witte <chris@witte.net.au> writes:
>
>> I'm having trouble getting the new version of babel to work with
>> haskell and R under Ubuntu 10.04 using emacs-snapshot.  It works fine
>> for emacs-lisp.  I had to change the variable LISPF in the Makefile
>> to:
>>
>> LISPF      =  org.el                          \
>> .....
>>               babel/ob.el                     \
>>               babel/ob-table.el               \
>>               babel/ob-lob.el                 \
>>               babel/ob-ref.el                 \
>>               babel/ob-exp.el                 \
>>               babel/ob-tangle.el              \
>>               babel/ob-comint.el              \
>>               babel/ob-keys.el                \
>>               babel/langs/ob-emacs-lisp.el    \
>>               babel/langs/ob-haskell.el       \
>>               babel/langs/ob-latex.el \
>>               babel/langs/ob-sh.el    \
>>               babel/langs/ob-asymptote.el     \
>>               babel/langs/ob-R.el     \
>>               babel/langs/ob-gnuplot.el
>>
>> otherwise I couldn't compile my .emacs file, which contains the following:
>>
>
> Hmm, I would think it would be possible to require files which are not
> byte-compiled.  The reason that the language files (aside from
> emacs-lisp) are not compiled by default is that they often have exotic
> requirements which will not be present on most users systems.
>
>>
>> (require 'org-install)
>>
>> ;;(require 'org)
>> ;;(require 'ob)
>> ;;(require 'ob-tangle)
>> ;; org-babel set up
>> (require 'ob-haskell)
>> (require 'ob-latex)
>> (require 'ob-sh)
>> (require 'ob-asymptote)
>> (require 'ob-R)
>> (require 'ob-gnuplot)
>>
>> The following works fine:
>>           #+tblname: example-table
>>           | 1 |
>>           | 2 |
>>           | 3 |
>>           | 4 |
>>
>>           #+source: table-length
>>           #+begin_src emacs-lisp  :var table=example-table
>>           (length table)
>>           #+end_src
>>
>>           #+results: table-length
>>         : 4
>>
>> But when I try the haskell equivalent:
>>           #+source: table-length
>>           #+begin_src haskell  :var table=example-table
>>           length table
>>           #+end_src
>>
>>
>> I get:
>> executing haskell source code block
>> reference 'example-table' not found in this buffer
>> org-babel-ref-resolve-reference: reference 'example-table' not found
>> in this buffer
>>
>> If I try:
>>           #+source: table-length
>>           #+begin_src haskell
>>           length [1,2,3]
>>           #+end_src
>>
>>
>> I get:
>> executing haskell source code block
>> org-babel-execute:haskell: Symbol's function definition is void: session
>>
>
> Thanks for bringing this up, it looks like ob-haskell has fallen victim
> to bit-rot.  I've done a fairly thorough cleanup of the file (just
> pushed up the commit).  Please give it a test run and let me know
> if/where I missed issues.
>
>>
>>
>> I also get a lot of warnings when I compile org-mode, see the attached
>> buiild log.
>>
>
> Yes, the language-specific files have not been manicured for clean
> byte-compilation.  This is certainly something that should happen, but
> probably not in the near term.
>
> Thanks -- Eric
>
>>
>>
>> Thanks for your help,
>>
>> Chris Witte.
>>
>> On 23 June 2010 23:09, Eric Schulte <schulte.eric@gmail.com> wrote:
>>> Hi,
>>>
>>> I've just merged the babel branch into the main branch of Org-mode.
>>> This merge culminates much integration work by Dan Davison and Tom Dye,
>>> as well as myself.
>>>
>>> Babel is now part of Org-mode.
>>>
>>> The biggest changes are:
>>>
>>> 1) Babel now has documentation!  It is part of Org-mode's documentation
>>>
>>>   see Chapter 14 _Working With Source Code_
>>>
>>>   also, the Babel keybindings are now listed in the refcard, and can be
>>>   viewed from any Org-mode buffer by pressing C-c C-v h
>>>
>>> 2) Babel will now be loaded by default along with the rest of Org-mode.
>>>   This means that *everyone* currently using babel will need to change
>>>   their Emacs config and remove the (require 'org-babel-int) and/or
>>>   (require 'org-babel) lines.
>>>
>>>   Support for evaluating emacs-lisp code blocks is loaded by default.
>>>   All other languages will need to be required explicitly.  To conform
>>>   to Emacs filename specifications all language require lines have been
>>>   shortened from e.g.
>>>
>>>   (require 'org-babel-sh)
>>>
>>>   to
>>>
>>>   (require 'ob-sh)
>>>
>>> Thanks -- 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
>>>
>>
>> _______________________________________________
>> 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
>

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

[Eric Schulte]

Hi Carsten,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi Eric, thanks for this.
>
> I would actually like to have a variable that will exclude evaluation
> from being added to the C-c C-c hook.  I think users will understand
> better how to use this, and customizing it will work for sure.
> Explicitly removing it from the hook will only work after load time.
>

I've made this change and updated it in the safety-babel branch, which
is also rebase'd against the current master head, so it will need to be
pulled with a "git pull -f" (and will overwrite any local changes you
have in that branch so be careful).

>
> We should also add
>
> (put 'org-confirm-babel-evaluate
>      'safe-local-variable
>      (lambda (x) (eq x t)))
>

This is also added

>
> After the definition of org-confirm-babel-evaluate to avoid that
> malicious code can change this setting through file variables.
>
> I have made a first draft of the security section in the manual,
> please take a look, add to it, and add a link to it from a good location
> in chapter 14.
>

I'm not able to find this section.  Which branch is it in?

Thanks -- Eric

>
> Cheers
>
> - Carsten
>
> On Jul 1, 2010, at 10:39 PM, Eric Schulte wrote:
>
>> Hi,
>>
>> Pursuant to the below, I've created a new "babel-safety" branch of the
>> repository.  It includes two new commits, the first of which
>> implements
>> confirmation before *any* code block evaluation, adds the keybinds for
>> code block evaluation, and adds a documentation for disassociating
>> code
>> block evaluation from C-c C-c.
>>
>> ,----[1d0b2f48c7f4b12b07dcfff0b5c1d29cc2c863bb]
>> | babel: evaluation of code blocks now requires confirmation
>> |
>> | * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to
>> |   control evaluation of code blocks, default value it t, meaning all
>> |   code block evaluation requires confirmation
>> |
>> |   (org-babel-confirm-evaluate): function used to request
>> confirmation
>> |   of code block evaluation from the user
>> |
>> |   (org-babel-execute-src-block): this function is the single point
>> of
>> |   entry for evaluation of code blocks (whether initiated through lob
>> |   call, through direct code block evaluation, or as part of file
>> |   exportation).  Every time this function is called it will now
>> |   request confirmation from the user.  The newly added
>> |   `org-confirm-babel-evaluate' variable can be used to configure
>> this
>> |   behavior.
>> |
>> | * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block
>> |   evaluation behavior
>> |
>> | * lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings
>> |   for executing code blocks and for opening their results
>> `----
>>
>> the second commit creates org-babel-load-languages, which can be
>> used to
>> enable or disable any babel language.
>>
>> ,----[5f5f41a206ccef10b8ff49af8c689995d05da37c]
>> | babel: `org-babel-load-languages' activates code blocks by language
>> |
>> | * lisp/org.el (org-babel-load-languages): this variable controls
>> which
>> |   languages will be loaded by org-babel.  It is customizable through
>> |   the customize interface.
>> |
>> |   (org-babel-do-load-languages): load those languages in
>> |   org-babel-load-languages and disable those with nil cdr's
>> `----
>>
>> While this variable works, and has a very nice customization widget
>> interface, it is awkward to customize from a user's configuration
>> file,
>> this is because it relies on the defcustom :set function with which is
>> it associated, and as far as I can tell, the only way to ensure that
>> the
>> set function is called, is to set this variable with something along
>> the
>> lines of the following in your configuration.
>>
>> --8<---------------cut here---------------start------------->8---
>> (org-babel-do-load-languages
>> 'org-babel-load-languages
>> '((emacs-lisp . nil)
>>   (ruby . t)
>>   (python . nil)
>>   (R . t)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> As of right now I can't think of a more natural way to implement
>> such a
>> variable -- suggestions welcom :).
>>
>> As I mentioned I'm keeping this is the babel-safety branch for now, as
>> it *will* disrupt the configuration and experience of Babel users, and
>> I've been hard on them already these past few weeks.  Maybe this is
>> best
>> folded into main along with the version 7.0 release so that it will be
>> accompanied with web-accessible documentation how to handle the
>> incomparable changes.
>>
>> Thanks -- Eric
>>
>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>
>>> Hi,
>>>
>>> Thanks for finding such a good compromises solution.  This new plan
>>> looks great to me, specifics below
>>>
>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>
>>>> Hi everyone,
>>>>
>>>> first of all, I think it is clear that I may have overreacted
>>>> with the "6 point plan".  But it is good that we are having
>>>> this discussion.
>>>>
>>>> On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote:
>>>>
>>>>> Hi Carsten, Matt, Scott,
>>>>>
>>>>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>>>>
>>>>>> Hi Matt, hi Eric,
>>>>>>
>>>>>> Matt, thanks a lot for bringing this up.  This is indeed a very
>>>>>> important and serious issue.  We need to address it.  We need to
>>>>>> step back and reconsider this carefully.
>>>>>>
>>>>>> Don't get me wrong, I absolutely think that Org Babel should give
>>>>>> you enough rope to hang yourself.  But we have to make sure that
>>>>>> this will not happen to a happy and unsuspecting Org mode, or even
>>>>>> an unsuspecting Emacs user who by chance opens a file with
>>>>>> extension
>>>>>> .org.
>>>>>>
>>>>>> I remember very well when  first realized that shell links could
>>>>>> really affect you badly.  It scared me.
>>>>>>
>>>>>> You main proposal was to make Org Babel an optional module.
>>>>>> This will not solve the problem fully, I think, because we also
>>>>>> don't want that people who turn it on automatically commit
>>>>>> to potentially dangerous operations.  There is a lot of good stuff
>>>>>> in Babel which has nothing to do with code evaluation.
>>>>>>
>>>>>> Here is what I propose (several items are similar to what Eric
>>>>>> proposes)
>>>>>>
>>>>>> 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.
>>>>
>>>> Actually, following Dan's argument, I am paddling back on this one.
>>>> Lets just keep it on.
>>>>
>>>> Instead of having a function to unload emacs-lisp, maybe a good way
>>>> would be a customize option org-babel-load-languages with a checkbox
>>>> for each language, emacs-lisp on by default.  This would make it
>>>> easy fo
>>>> people to select the languages they want, without having to add
>>>> several require statements to .emacs.
>>>>
>>>
>>> This sounds like a good idea, such a variable would also play the
>>> important role of advertising what languages currently support
>>> execution
>>> in Babel.  One issue with this setup is that I think languages
>>> which do
>>> not have FSF attribution (currently only oz) would still require an
>>> explicit `require' statement, however that shouldn't be too
>>> surprising
>>> as those statements live in the contrib directory, and users should
>>> be
>>> used to having to explicitly require functionality located in
>>> contrib.
>>>
>>> One nice thing about this setup is that it shouldn't break user's
>>> current config (existing `require' statements will still work).
>>>
>>>>
>>>>>>
>>>>>> 2. As Eric proposes, a variable similar to org-confirm-shell-link-
>>>>>> function
>>>>>> This should by default query for confirmation on any org-babel
>>>>>> code execution, and can be configured to shut up by people who
>>>>>> know
>>>>>> what they are doing.
>>>>>>
>>>>>
>>>>> Sounds good, I think this is a reasonable safety measure.
>>>>>
>>>>>>
>>>>>> 3. Not loading emacs lisp evaluation by default.
>>>>>>
>>>>>
>>>>> I would push back on this point.  Largely because we have now
>>>>> crossed
>>>>> the like to where it is impossible to play with a code block w/o
>>>>> first
>>>>> dropping down to your configuration files, and evaluating require
>>>>> statements.
>>>>>
>>>>>>
>>>>>> 4. A new key in the babel keymap for org-babel-execute-code-block,
>>>>>> for example `C-c C-v e'.  This should be documented as the default
>>>>>> key for this operation.
>>>>>>
>>>>>
>>>>> Hmm, I'm less enthusiastic about this point and point 5.  I really
>>>>> like
>>>>> how 'C-c C-c' naturally does whatever-I-want given the context in
>>>>> which
>>>>> it's called, and I wouldn't want to lose that intuitiveness.
>>>>> Similarly
>>>>> 'C-c C-o' currently opens the results of a code block, I also find
>>>>> this
>>>>> very appealing as it allows for a uniform top-level interface
>>>>> across
>>>>> an
>>>>> Org-mode document, be it a code block or a link.
>>>>>
>>>>> Here are my reasons why I think leaving this keybinding is safe.
>>>>>
>>>>> 1) Unlike with shell/elisp links, the contents of code blocks is
>>>>> almost
>>>>> always visible right under the user's point.  So it is less
>>>>> likely to
>>>>> evaluate something w/o having any idea what you are evaluating.
>>>>>
>>>>> 2) Adding a protection variable (e.g. org-confirm-babel-eval) means
>>>>> that
>>>>> the only users who could potentially evaluate a code block with a
>>>>> slip of the fingers would be users who have explicitly said that
>>>>> they
>>>>> want to be able to easily run code blocks without confirmation.
>>>>>
>>>>> 3) Emacs exposes a number of entry points into code evaluation.
>>>>> M-!
>>>>> allows users to run shell commands, C-M-x evaluate the elisp at
>>>>> point, and these have not caused problems in the past.
>>>>
>>>> These are all very well taken points.  And I agree that a somewhat
>>>> regular Org-mode user should be protected by this well enough.
>>>>
>>>> There are actually two kinds of users and two levels where
>>>> we need to think about this.
>>>>
>>>> 1. I am worried about is this:  Org mode (including Babel)
>>>> will soon be part of Emacs an be shipped to a very large number of
>>>> people who have nothing to do with Org mode and might pick a file
>>>> of the web to try playing with it.  I want to protect these users
>>>> and
>>>> also us, as the Org mode community, from a stupid accident happening
>>>> like that. But, in fact, a yes-or-no-p confirmation would probably
>>>> cover this well enough. OK for this part.  BTW, Eric,
>>>> I think this confirmation variable should also be allowed to take
>>>> a function with a two arguments, the language of the snippet
>>>> and the snippet.  Users could then write a function which would
>>>> get confirmation for some snippets, but not for others.
>>>>
>>>
>>> This sounds like a good idea.  I'll update the confirmation
>>> function as
>>> you've described.  One possible issue here is that with complicated
>>> setups, a single action could require multiple confirmations -- as
>>> executing one code block can call on other code blocks as
>>> arguments, but
>>> I think that behavior is required to ensure that the user is fully
>>> aware
>>> of the full extent of the processes taking place.
>>>
>>>>
>>>> 2. The other thing is that I am afraid of myself in this context.
>>>> I envision myself turning off the check eval confirmation check
>>>> sooner
>>>> rather than later because I don't like to press the confirmation key
>>>> all the time.  Repetitive things like this annoy me and I turn
>>>> them off.
>>>> So I am happily working with code in a document fine.
>>>>
>>>> Later, I see myself accidentally pressing C-c C-c in a place where
>>>> I did
>>>> not mean to press it.  Like in Matt's example, this could be a
>>>> blog post
>>>> or any other document where I have some source code examples.
>>>> I press key combinations with C-c *so* many times
>>>> a day that a couple of `C-c C-c' come up by accident every day.
>>>> In fact, in this context I am more worried about `C-c C-c' than `C-c
>>>> C-
>>>> o'
>>>> This is why I was proposing to not have this in C-c C-c (and, now
>>>> you mention it, in C-c C-o) by default.  I definitely think
>>>> that it would be good to give users a variable to not include
>>>> these into `C-c C-c' and `C-c C-o'.  Having additional bindings
>>>> for these two commands in the `C-c C-v' map would not hurt in
>>>> any case.
>>>>
>>>> On the other hand, I totally see how C-c C-c is a great and
>>>> natural binding if you wan to work with source code, of cause,
>>>> and I do understand why you defend it and want to have it in by
>>>> default.
>>>>
>>>
>>> Thanks for your understanding on this point.
>>>
>>>>
>>>> So in summary, I think I could be fine with a situation
>>>> where the variable I just described exists and is set
>>>> so that C-c C-c and C-c C-o do the evaluation, and where
>>>> the issues are clearly documented.
>>>>
>>>
>>> I see your point, and I think your proposed solution is a good
>>> compromise.  I'll add C-c C-v keybindings for both evaluation and
>>> opening of code blocks.  Also, I'll add a variable which can be
>>> used to
>>> disable the binding of code block execution to C-c C-c.  We can also
>>> mention this variable in the documentation for the confirmation
>>> variable, so that as users disable block confirmation they will
>>> (hopefully) read the documentation of the variable they are
>>> disabling,
>>> and will stop and think "maybe in a world w/o confirmation, I'd feel
>>> safer using a higher friction keybinding".
>>>
>>> BTW: any suggestions for C-c C-v key bindings, I'm thinking of the
>>> following, but there may be options with better ergonomics.
>>> | C-c C-v e | for code block execution, mnemonic "execute" |
>>> | C-c C-v o | for opening of results, mnemonic "open"      |
>>>
>>> Thanks -- Eric
>>>
>>>>
>>>> - Carsten
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> 5. Removing org-babel-execute-code-block from `C-c C-c'.
>>>>>> Inclusion
>>>>>> should be optional.
>>>>>>
>>>>>> 6. A section in the manual on code execution and associated
>>>>>> security
>>>>>> risks in Org mode.  This is not only about babel, but also about
>>>>>> org-eval, org-eval-light, shell links and elisp links.  I have
>>>>>> meant
>>>>>> to write this section for a long time and would be willing to
>>>>>> draft it. We could then refer to this section from a couple of
>>>>>> places in the docs, without cluttering the docs with disclaimers.
>>>>>>
>>>>>
>>>>> This sounds like a very good idea.  I'd be happy to help write
>>>>> such a
>>>>> section.
>>>>>
>>>>>>
>>>>>> The reason for 4 and 5 is that I believe Org-mode users are
>>>>>> trained
>>>>>> to blindly press `C-c C-c' whenever they want to update
>>>>>> something at
>>>>>> point.  Matt's example of a blog post about `rm -rf' is a very
>>>>>> realistic example for bad code being evaluated by mistake, not
>>>>>> even
>>>>>> due to malicious cations.  I belive that a special key for this
>>>>>> action would gove a good measure of protection.
>>>>>>
>>>>>
>>>>> As I mentioned, I personally feel that an org-confirm-babel-eval
>>>>> variable is sufficient protection.  I think it's safe to assume
>>>>> that
>>>>> if
>>>>> a user has explicitly customized that variable, then they know what
>>>>> they're doing and trust themselves to execute code responsibly.  I
>>>>> think
>>>>> it's likely that the casual Org-babel user would never customize
>>>>> this
>>>>> variable, which seems to me entirely appropriate.
>>>>>
>>>>>>
>>>>>> This is what I think - please let me know if you think I am
>>>>>> overdoing
>>>>>> it.
>>>>>>
>>>>>
>>>>> So to summarize, I think that the combination of (1), (2) and (6),
>>>>> should be sufficient to protect users from accidental code
>>>>> evaluation.
>>>>> Please let me know what you think, I am of course looking to
>>>>> compromise
>>>>> and I fully understand that the general consensus may be that we
>>>>> need
>>>>> more layers of protection.
>>>>>
>>>>> Best -- Eric
>>>>>
>>>>>>
>>>>>> - Carsten
>>>>>>
>>>>>>
>>>>>> On Jun 29, 2010, at 8:23 PM, Matt Lundin wrote:
>>>>>>
>>>>>>> Hi Eric,
>>>>>>>
>>>>>>> Thanks again for all the work that you, Dan, and Tom have put
>>>>>>> into
>>>>>>> org-babel. I'm glad to see it become part of org-mode!
>>>>>>>
>>>>>>> "Eric Schulte" <schulte.eric@gmail.com> writes:
>>>>>>>
>>>>>>>> 2) Babel will now be loaded by default along with the rest of
>>>>>>>> Org-
>>>>>>>> mode.
>>>>>>>> This means that *everyone* currently using babel will need to
>>>>>>>> change
>>>>>>>> their Emacs config and remove the (require 'org-babel-int)
>>>>>>>> and/
>>>>>>>> or
>>>>>>>> (require 'org-babel) lines.
>>>>>>>
>>>>>>> I would like to request that org-babel be made an optional
>>>>>>> module. I
>>>>>>> ask
>>>>>>> this as someone who uses org-babel regularly. Here are my
>>>>>>> reasons:
>>>>>>>
>>>>>>> - Org-babel adds rather specific and complex functionality to
>>>>>>> org-
>>>>>>> mode
>>>>>>> that those who use it as a simple outliner and todo manager do
>>>>>>> not
>>>>>>> require. (In other words, an option to turn it off might be nice
>>>>>>> for
>>>>>>> those who are worried about "feature creep.")
>>>>>>>
>>>>>>> - Org-babel increases the risk of accidentally executing
>>>>>>> malicious
>>>>>>> or
>>>>>>> dangerous code when typing C-c C-c on a src block or exporting a
>>>>>>> file. Perhaps users should activate it only after they understand
>>>>>>> the risks.
>>>>>>>
>>>>>>> + For instance, I might write a blog post warning about the
>>>>>>> dangers
>>>>>>>   of typing "rm -rf ~/". If I put this between #+begin_src sh
>>>>>>>   and #+end_src and unthinkingly hit C-c C-c, I would be in
>>>>>>> trouble.
>>>>>>>   I believe this is the reason for the variables
>>>>>>>   org-confirm-shell-link-function and
>>>>>>>   org-confirm-elisp-link-function.
>>>>>>>
>>>>>>> + This is admitted a bit far-fetched as an example, as it would
>>>>>>>   require one to have loaded ob-sh.el. But since elisp
>>>>>>> execution is
>>>>>>>   activated by default, there remain opportunities for
>>>>>>> unwittingly
>>>>>>>   executing code that is meant for other purposes (e.g.,
>>>>>>> warnings,
>>>>>>>   examples, etc.).
>>>>>>>
>>>>>>>> Support for evaluating emacs-lisp code blocks is loaded by
>>>>>>>> default.
>>>>>>>> All other languages will need to be required explicitly.  To
>>>>>>>> conform
>>>>>>>> to Emacs filename specifications all language require lines have
>>>>>>>> been
>>>>>>>> shortened from e.g.
>>>>>>>>
>>>>>>>> (require 'org-babel-sh)
>>>>>>>>
>>>>>>>> to
>>>>>>>>
>>>>>>>> (require 'ob-sh)
>>>>>>>
>>>>>>> When I run make clean && make && make install I find that the
>>>>>>> language
>>>>>>> directory is not installed. Does the langs directory require a
>>>>>>> manual
>>>>>>> installation?
>>>>>>>
>>>>>>> Also, with make install, the ob-* files are installed on the same
>>>>>>> level
>>>>>>> as the org-files, yet lines 108-114 in org.el indicate that they
>>>>>>> should
>>>>>>> be installed in a babel subdirectory.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Matt
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>> - Carsten
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>> - Carsten
>
> - Carsten