Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Carsten, Carsten Dominik 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" writes: >> >>> Hi, >>> >>> Thanks for finding such a good compromises solution. This new plan >>> looks great to me, specifics below >>> >>> Carsten Dominik 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, > >
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 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 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 u
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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" writes: Hi, Thanks for finding such a good compromises solution. This new plan looks great to me, specifics below Carsten Dominik 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 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
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Sébastien Vauban wrote: > Nick Dokos wrote: > > Carsten Dominik 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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" writes: Hi, Thanks for finding such a good compromises solution. This new plan looks great to me, specifics below Carsten Dominik 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 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 sh
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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" writes: > Hi, > > Thanks for finding such a good compromises solution. This new plan > looks great to me, specifics below > > Carsten Dominik 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 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 >>> de
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Nick, Nick Dokos wrote: > Carsten Dominik 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@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Carsten Dominik 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... ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi, Thanks for finding such a good compromises solution. This new plan looks great to me, specifics below Carsten Dominik 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 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
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Jun 30, 2010, at 7:01 PM, Dan Davison wrote: "Eric Schulte" writes: Hi Carsten, Matt, Scott, Carsten Dominik 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 r
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Dan Davison writes: > "Eric Schulte" writes: > >> Carsten Dominik 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi,
just to throw yet another idea into the discussion:
Execute source blocks only after the user confirmed it ("Do you know
what you are doing (Type y, n, !, or SPC)?"). ! and SPC will add the
current org file to the variables org-babel-trusted-files and
org-babel-trusted-permanently-files (also C-c C-v [ and C-u C-c C-v [
could do this). The latter will be saved for future sessions. And if
you also had a command to clean up this variable, removing
non-existing and/or old files from it...
This way the control of code execution by org-babel would be on the file
level instead of the global level.
Greetings,
Stephan
Also sprach Eric Schulte:
Dan Davison writes:
"Eric Schulte" writes:
Hi Carsten, Matt, Scott,
Carsten Dominik writes:
[...]
1. A new variable org-turn-on-babel. We can discuss the default.
If it is nil, org-babel should not be loaded.
A default of t would be fine with me if we implement other
measures listed below.
This sounds like a good idea to me, and it should address Matt's desire
for enabling minimal Org-mode installs. I would like this to default to
t, so that new users can try out Org-babel without overmuch effort.
I'm not clear yet what the point of this is. Unless it is the load time
which is the issue, what else is gained by this variable? In principle
I'm also all for minimalism and modularity, but what does it actually
mean here?
If the effect of this variable is to not load org-babel code at all,
then this needs to be thought about carefully, as it is tantamount to a
statement that all org-babel code is orthogonal to the rest of
org-mode. I.e. core org-mode will not be able to make use of any
org-babel code, because there will always be the risk that the user has
set this variable to nil. Are we sure that we might not want some
org-babel code (e.g. block export or tangling or something) to be used
in core Org functionality?
As an example of an area of overlap of core org-mode and babel, I'd been
considering extending the [[shell:]] and [[elisp:]] links that are
present in core Org-mode to support other languages. If that happens it
might make sense to let babel code handle the shell and elisp
evaluation, rather than having that functionality duplicated in the code
base.
Essentially I had been envisioning the incorporation of org-babel into
org-mode as the beginning of a phase in which the code bases can
interact and evolve together, rather than as a promise of eternal
orthogonality.
Thanks for bringing this up Dan, I think you're right that this is a
very important point, which I had missed in my rush to defend the
evaluation 'C-c C-c' keybinding. For simplicity, for maintainability,
for code cleanliness, and to remove significant duplication of code and
functionality, I agree that it is important for Babel to be part of
Org-mode rather than a detachable module.
As an alternative to adding a configuration option to strip all of Babel
out of Org-mode, perhaps we should add an option for users who are sure
that they will never want to evaluate code blocks to *not* load
emacs-lisp support. With no language support loaded, then all of the
Babel functions are part of Org-mode, but there is no way that any
source code can actually be executed.
Best -- Eric
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
___
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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
"Eric Schulte" writes: > Matt Lundin 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 >From 993dda2b88220a994422becdef11773986094ce6 Mon Sep 17 00:00:00 2001 From: Eric Schulte 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 +
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Matt Lundin 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Dan Davison writes: > "Eric Schulte" writes: > >> Hi Carsten, Matt, Scott, >> >> Carsten Dominik writes: >> [...] >>> 1. A new variable org-turn-on-babel. We can discuss the default. >>>If it is nil, org-babel should not be loaded. >>>A default of t would be fine with me if we implement other >>>measures listed below. >>> >> >> This sounds like a good idea to me, and it should address Matt's desire >> for enabling minimal Org-mode installs. I would like this to default to >> t, so that new users can try out Org-babel without overmuch effort. > > I'm not clear yet what the point of this is. Unless it is the load time > which is the issue, what else is gained by this variable? In principle > I'm also all for minimalism and modularity, but what does it actually > mean here? > > If the effect of this variable is to not load org-babel code at all, > then this needs to be thought about carefully, as it is tantamount to a > statement that all org-babel code is orthogonal to the rest of > org-mode. I.e. core org-mode will not be able to make use of any > org-babel code, because there will always be the risk that the user has > set this variable to nil. Are we sure that we might not want some > org-babel code (e.g. block export or tangling or something) to be used > in core Org functionality? > > As an example of an area of overlap of core org-mode and babel, I'd been > considering extending the [[shell:]] and [[elisp:]] links that are > present in core Org-mode to support other languages. If that happens it > might make sense to let babel code handle the shell and elisp > evaluation, rather than having that functionality duplicated in the code > base. > > Essentially I had been envisioning the incorporation of org-babel into > org-mode as the beginning of a phase in which the code bases can > interact and evolve together, rather than as a promise of eternal > orthogonality. > Thanks for bringing this up Dan, I think you're right that this is a very important point, which I had missed in my rush to defend the evaluation 'C-c C-c' keybinding. For simplicity, for maintainability, for code cleanliness, and to remove significant duplication of code and functionality, I agree that it is important for Babel to be part of Org-mode rather than a detachable module. As an alternative to adding a configuration option to strip all of Babel out of Org-mode, perhaps we should add an option for users who are sure that they will never want to evaluate code blocks to *not* load emacs-lisp support. With no language support loaded, then all of the Babel functions are part of Org-mode, but there is no way that any source code can actually be executed. Best -- Eric ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
"Eric Schulte" writes: > Hi Carsten, Matt, Scott, > > Carsten Dominik 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
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Carsten, Matt, Scott, Carsten Dominik 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 accid
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Eric, Thanks so much for taking these observations into account. "Eric Schulte" writes: > Thanks for raising the point about potentially dangerous code blocks. > > Matt Lundin 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" 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Tue, Jun 29, 2010 at 11:03 PM, Eric Schulte 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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" 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
non-empty attachment 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/nout
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Nick Dokos writes: > Eric Schulte 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Eric Schulte 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
with attachment ;)
>From 24f99a2ebd3de464fdb60902f003b828c2f71003 Mon Sep 17 00:00:00 2001
From: Eric Schulte
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 ;
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi all, "Eric Schulte" writes: > Hi Matt, > > Thanks for raising the point about potentially dangerous code blocks. > > Matt Lundin 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Matt Lundin 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 /lisp/babel. > > What does 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Matt, Thanks for raising the point about potentially dangerous code blocks. Matt Lundin 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" 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 ma
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Matt Lundin 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Nick, Nick Dokos writes: > Matt Lundin 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 /lisp/babel. What does 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Matt Lundin 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 /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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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" 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
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Mon, Jun 28, 2010 at 6:03 PM, Eric Schulte wrote: > Hi Rainer, > > I'm happy this was useful > > Rainer M Krug writes: > > > On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte >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: rai...@krugs.de Skype: RMkrug Google: r.m.k...@gmail.com ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Rainer, I'm happy this was useful Rainer M Krug writes: > On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
2010/6/28 Bernt Hansen > Rainer M Krug writes: > > > I updated my org-mode directory with the following script: > > > > rk...@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: rai...@krugs.de Skype: RMkrug Google: r.m.k...@gmail.com ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Rainer M Krug writes: > I updated my org-mode directory with the following script: > > rk...@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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
2010/6/28 Bernt Hansen > Rainer M Krug writes: > > > On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec wrote: > > > > Rainer M Krug 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: rk...@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: rai...@krugs.de Skype: RMkrug Google: r.m.k...@gmail.com ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Rainer M Krug writes: > On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec wrote: > > Rainer M Krug 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec wrote: > Rainer M Krug 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: rai...@krugs.de Skype: RMkrug Google: r.m.k...@gmail.com ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Rainer M Krug 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte 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 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)
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Carsten Dominik writes: > On Jun 26, 2010, at 6:30 PM, Štěpán Němec wrote: > >> "Eric Schulte" writes: >> >>> Štěpán Němec 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Jun 26, 2010, at 6:30 PM, Štěpán Němec wrote: "Eric Schulte" writes: Štěpán Němec 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Also sprach Eric Schulte: Štěpán Němec writes: "Eric Schulte" writes: Štěpán Němec 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Štěpán Němec writes: > "Eric Schulte" writes: > >> Štěpán Němec 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
"Eric Schulte" writes: > Štěpán Němec 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Štěpán Němec 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
"Eric Schulte" 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 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 enti
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 wrote:
> Hi Sébastien,
>
> Sébastien Vauban 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 -- Er
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 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
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Sébastien,
Sébastien Vauban 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Nathan, Nathan Neff 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 ___ 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: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
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 | 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 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 ___ 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Bernt Hansen writes: > > The documentation still has (require 'org-babel-identifier) and should > probably be updated. > updated, 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
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
"Eric Schulte" 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 ___ 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
