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 carsten.domi...@gmail.com writes: Hi everyone, first of all, I think it is clear that I may have overreacted with the 6 point plan. But it is good that we are having this discussion. On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote: Hi Carsten, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module. This will not solve the problem fully, I think, because we also don't want that people who turn it on automatically commit to potentially dangerous operations. There is a lot of good stuff in Babel which has nothing to do with code evaluation. Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. This sounds like a good idea to me, and it should address Matt's desire for enabling minimal Org-mode installs. I would like this to default to t, so that new users can try out Org-babel without overmuch effort. Actually, following Dan's argument, I am paddling back on this one. Lets just keep it on. Instead of having a function to unload emacs-lisp, maybe a good way would be a customize option org-babel-load-languages with a checkbox for each language, emacs-lisp on by default. This would make it easy fo people to select the languages they want, without having to add several require statements to .emacs. This sounds like a good idea, such a variable would also play the important role of advertising what languages currently support execution in Babel. One issue with this setup is that I think languages which do not have FSF attribution (currently only oz) would still require an explicit `require' statement, however that shouldn't be too surprising as those statements live in the contrib directory, and users should be used to having to explicitly require functionality located in contrib. One nice thing about this setup is that it shouldn't break user's current config (existing `require' statements will still work). 2. As Eric proposes, a variable similar to org-confirm-shell-link- function This should by default query for confirmation on any org-babel code execution, and can be configured to shut up by people who know what they are doing. Sounds good, I think this is a reasonable safety measure. 3. Not loading emacs lisp evaluation by default. I would push back on this point. Largely because we have now crossed the like to where it is impossible to play with a code block w/o first dropping down to your configuration files, and evaluating require statements. 4. A new key in the babel keymap for org-babel-execute-code-block, for example `C-c C-v e'. This should be documented as the default key for this operation. Hmm, I'm less enthusiastic about this point and point 5. I really like how 'C-c C-c' naturally does whatever-I-want given the context in which it's called, and I wouldn't want to lose that intuitiveness. Similarly 'C-c C-o' currently opens the results of a code block, I also find this very appealing as it allows for a uniform top-level interface across an Org-mode document, be it a code block or a link. Here are my reasons why I think leaving this keybinding is safe. 1) Unlike with shell/elisp links, the contents of code blocks is almost always visible right under the user's point. So it is less likely to evaluate something w/o having any idea what you are evaluating. 2) Adding a protection variable (e.g. org-confirm-babel-eval) means that the only users who could potentially evaluate a code block with a slip of the fingers would be users who have explicitly said that they want to be able to easily run code blocks without confirmation. 3) Emacs exposes a number of entry points into code evaluation. M-! allows users to run shell commands, C-M-x evaluate the elisp at point, and these have not caused problems in the past. These are all very well taken
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Carsten, Carsten Dominik carsten.domi...@gmail.com writes: Hi Eric, thanks for this. I would actually like to have a variable that will exclude evaluation from being added to the C-c C-c hook. I think users will understand better how to use this, and customizing it will work for sure. Explicitly removing it from the hook will only work after load time. I've made this change and updated it in the safety-babel branch, which is also rebase'd against the current master head, so it will need to be pulled with a git pull -f (and will overwrite any local changes you have in that branch so be careful). We should also add (put 'org-confirm-babel-evaluate 'safe-local-variable (lambda (x) (eq x t))) This is also added After the definition of org-confirm-babel-evaluate to avoid that malicious code can change this setting through file variables. I have made a first draft of the security section in the manual, please take a look, add to it, and add a link to it from a good location in chapter 14. I'm not able to find this section. Which branch is it in? Thanks -- Eric Cheers - Carsten On Jul 1, 2010, at 10:39 PM, Eric Schulte wrote: Hi, Pursuant to the below, I've created a new babel-safety branch of the repository. It includes two new commits, the first of which implements confirmation before *any* code block evaluation, adds the keybinds for code block evaluation, and adds a documentation for disassociating code block evaluation from C-c C-c. ,[1d0b2f48c7f4b12b07dcfff0b5c1d29cc2c863bb] | babel: evaluation of code blocks now requires confirmation | | * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to | control evaluation of code blocks, default value it t, meaning all | code block evaluation requires confirmation | | (org-babel-confirm-evaluate): function used to request confirmation | of code block evaluation from the user | | (org-babel-execute-src-block): this function is the single point of | entry for evaluation of code blocks (whether initiated through lob | call, through direct code block evaluation, or as part of file | exportation). Every time this function is called it will now | request confirmation from the user. The newly added | `org-confirm-babel-evaluate' variable can be used to configure this | behavior. | | * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block | evaluation behavior | | * lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings | for executing code blocks and for opening their results ` the second commit creates org-babel-load-languages, which can be used to enable or disable any babel language. ,[5f5f41a206ccef10b8ff49af8c689995d05da37c] | babel: `org-babel-load-languages' activates code blocks by language | | * lisp/org.el (org-babel-load-languages): this variable controls which | languages will be loaded by org-babel. It is customizable through | the customize interface. | | (org-babel-do-load-languages): load those languages in | org-babel-load-languages and disable those with nil cdr's ` While this variable works, and has a very nice customization widget interface, it is awkward to customize from a user's configuration file, this is because it relies on the defcustom :set function with which is it associated, and as far as I can tell, the only way to ensure that the set function is called, is to set this variable with something along the lines of the following in your configuration. --8---cut here---start-8--- (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (ruby . t) (python . nil) (R . t))) --8---cut here---end---8--- As of right now I can't think of a more natural way to implement such a variable -- suggestions welcom :). As I mentioned I'm keeping this is the babel-safety branch for now, as it *will* disrupt the configuration and experience of Babel users, and I've been hard on them already these past few weeks. Maybe this is best folded into main along with the version 7.0 release so that it will be accompanied with web-accessible documentation how to handle the incomparable changes. Thanks -- Eric Eric Schulte schulte.e...@gmail.com writes: Hi, Thanks for finding such a good compromises solution. This new plan looks great to me, specifics below Carsten Dominik carsten.domi...@gmail.com writes: Hi everyone, first of all, I think it is clear that I may have overreacted with the 6 point plan. But it is good that we are having this discussion. On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote: Hi Carsten, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Jun 30, 2010, at 7:01 PM, Dan Davison wrote: Eric Schulte schulte.e...@gmail.com writes: Hi Carsten, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module. This will not solve the problem fully, I think, because we also don't want that people who turn it on automatically commit to potentially dangerous operations. There is a lot of good stuff in Babel which has nothing to do with code evaluation. Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. This sounds like a good idea to me, and it should address Matt's desire for enabling minimal Org-mode installs. I would like this to default to t, so that new users can try out Org-babel without overmuch effort. I'm not clear yet what the point of this is. Unless it is the load time which is the issue, what else is gained by this variable? In principle I'm also all for minimalism and modularity, but what does it actually mean here? If the effect of this variable is to not load org-babel code at all, then this needs to be thought about carefully, as it is tantamount to a statement that all org-babel code is orthogonal to the rest of org-mode. I.e. core org-mode will not be able to make use of any org-babel code, because there will always be the risk that the user has set this variable to nil. Are we sure that we might not want some org-babel code (e.g. block export or tangling or something) to be used in core Org functionality? Like Eric, I agree. As an example of an area of overlap of core org-mode and babel, I'd been considering extending the [[shell:]] and [[elisp:]] links that are present in core Org-mode to support other languages. If that happens it might make sense to let babel code handle the shell and elisp evaluation, rather than having that functionality duplicated in the code base. :-) Actually, in this specific area I had been thinking to removing or at least deprecating shell and elisp links, because the Org-babel way is much better and clearer to have that code in a block, rather than hiding it in the invisible part of of a link. Essentially I had been envisioning the incorporation of org-babel into org-mode as the beginning of a phase in which the code bases can interact and evolve together, rather than as a promise of eternal orthogonality. Yes, I agree. This is definitely the point of this integration. - Carsten 2. As Eric proposes, a variable similar to org-confirm-shell-link- function This should by default query for confirmation on any org-babel code execution, and can be configured to shut up by people who know what they are doing. Sounds good, I think this is a reasonable safety measure. Yes, I think this is the key. Other than the doubts expressed above I agree with what Eric wrote. Dan 3. Not loading emacs lisp evaluation by default. I would push back on this point. Largely because we have now crossed the like to where it is impossible to play with a code block w/o first dropping down to your configuration files, and evaluating require statements. 4. A new key in the babel keymap for org-babel-execute-code-block, for example `C-c C-v e'. This should be documented as the default key for this operation. Hmm, I'm less enthusiastic about this point and point 5. I really like how 'C-c C-c' naturally does whatever-I-want given the context in which it's called, and I wouldn't want to lose that intuitiveness. Similarly 'C-c C-o' currently opens the results of a code block, I also find this very appealing as it allows for a uniform top-level interface across an Org-mode document, be it a code block or a link. Here are my reasons why I think leaving this keybinding is safe. 1) Unlike with shell/elisp links, the contents of code blocks is almost always visible right under the user's point. So it is less likely to evaluate something w/o having any idea what you are evaluating. 2) Adding a protection variable (e.g. org-confirm-babel-eval) means that the only users who could potentially evaluate a code block with a slip of the fingers would be users who have explicitly
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 carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module. This will not solve the problem fully, I think, because we also don't want that people who turn it on automatically commit to potentially dangerous operations. There is a lot of good stuff in Babel which has nothing to do with code evaluation. Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. This sounds like a good idea to me, and it should address Matt's desire for enabling minimal Org-mode installs. I would like this to default to t, so that new users can try out Org-babel without overmuch effort. Actually, following Dan's argument, I am paddling back on this one. Lets just keep it on. Instead of having a function to unload emacs-lisp, maybe a good way would be a customize option org-babel-load-languages with a checkbox for each language, emacs-lisp on by default. This would make it easy fo people to select the languages they want, without having to add several require statements to .emacs. 2. As Eric proposes, a variable similar to org-confirm-shell-link- function This should by default query for confirmation on any org-babel code execution, and can be configured to shut up by people who know what they are doing. Sounds good, I think this is a reasonable safety measure. 3. Not loading emacs lisp evaluation by default. I would push back on this point. Largely because we have now crossed the like to where it is impossible to play with a code block w/o first dropping down to your configuration files, and evaluating require statements. 4. A new key in the babel keymap for org-babel-execute-code-block, for example `C-c C-v e'. This should be documented as the default key for this operation. Hmm, I'm less enthusiastic about this point and point 5. I really like how 'C-c C-c' naturally does whatever-I-want given the context in which it's called, and I wouldn't want to lose that intuitiveness. Similarly 'C-c C-o' currently opens the results of a code block, I also find this very appealing as it allows for a uniform top-level interface across an Org-mode document, be it a code block or a link. Here are my reasons why I think leaving this keybinding is safe. 1) Unlike with shell/elisp links, the contents of code blocks is almost always visible right under the user's point. So it is less likely to evaluate something w/o having any idea what you are evaluating. 2) Adding a protection variable (e.g. org-confirm-babel-eval) means that the only users who could potentially evaluate a code block with a slip of the fingers would be users who have explicitly said that they want to be able to easily run code blocks without confirmation. 3) Emacs exposes a number of entry points into code evaluation. M-! allows users to run shell commands, C-M-x evaluate the elisp at point, and these have not caused problems in the past. These are all very well taken points. And I agree that a somewhat regular Org-mode user should be protected by this well enough. There are actually two kinds of users and two levels where we need to think about this. 1. I am worried about is this: Org mode (including Babel) will soon be part of Emacs an be shipped to a very large number of people who have nothing to do with Org mode and might pick a file of the web to try playing with it. I want to protect these users and also us, as the Org mode community, from a stupid accident happening like that. But, in fact, a yes-or-no-p confirmation would probably cover this well enough. OK for this part. BTW, Eric, I think this confirmation variable should also be allowed to take a function with a two arguments, the language of the snippet and the snippet. Users could then write a function which would get confirmation for some snippets, but not for others. 2. The other thing is that I am afraid of myself in this context. I envision myself turning off the check eval
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 carsten.domi...@gmail.com writes: Hi everyone, first of all, I think it is clear that I may have overreacted with the 6 point plan. But it is good that we are having this discussion. On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote: Hi Carsten, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module. This will not solve the problem fully, I think, because we also don't want that people who turn it on automatically commit to potentially dangerous operations. There is a lot of good stuff in Babel which has nothing to do with code evaluation. Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. This sounds like a good idea to me, and it should address Matt's desire for enabling minimal Org-mode installs. I would like this to default to t, so that new users can try out Org-babel without overmuch effort. Actually, following Dan's argument, I am paddling back on this one. Lets just keep it on. Instead of having a function to unload emacs-lisp, maybe a good way would be a customize option org-babel-load-languages with a checkbox for each language, emacs-lisp on by default. This would make it easy fo people to select the languages they want, without having to add several require statements to .emacs. This sounds like a good idea, such a variable would also play the important role of advertising what languages currently support execution in Babel. One issue with this setup is that I think languages which do not have FSF attribution (currently only oz) would still require an explicit `require' statement, however that shouldn't be too surprising as those statements live in the contrib directory, and users should be used to having to explicitly require functionality located in contrib. One nice thing about this setup is that it shouldn't break user's current config (existing `require' statements will still work). 2. As Eric proposes, a variable similar to org-confirm-shell-link- function This should by default query for confirmation on any org-babel code execution, and can be configured to shut up by people who know what they are doing. Sounds good, I think this is a reasonable safety measure. 3. Not loading emacs lisp evaluation by default. I would push back on this point. Largely because we have now crossed the like to where it is impossible to play with a code block w/o first dropping down to your configuration files, and evaluating require statements. 4. A new key in the babel keymap for org-babel-execute-code-block, for example `C-c C-v e'. This should be documented as the default key for this operation. Hmm, I'm less enthusiastic about this point and point 5. I really like how 'C-c C-c' naturally does whatever-I-want given the context in which it's called, and I wouldn't want to lose that intuitiveness. Similarly 'C-c C-o' currently opens the results of a code block, I also find this very appealing as it allows for a uniform top-level interface across an Org-mode document, be it a code block or a link. Here are my reasons why I think leaving this keybinding is safe. 1) Unlike with shell/elisp links, the contents of code blocks is almost always visible right under the user's point. So it is less likely to evaluate something w/o having any idea what you are evaluating. 2) Adding a protection variable (e.g. org-confirm-babel-eval) means that the only users who could potentially evaluate a code block with a slip of the fingers would be users who have explicitly said that they want to be able to easily run code blocks without confirmation. 3) Emacs exposes a number of entry points into code evaluation. M-! allows users to run shell commands, C-M-x evaluate the elisp at point, and these have not caused problems in the past. These are all very well taken points. And I agree that a somewhat regular Org-mode user should be protected by this well enough. There are actually two kinds of users and two levels where we need to
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Carsten Dominik carsten.domi...@gmail.com wrote: :-) Actually, in this specific area I had been thinking to removing or at least deprecating shell and elisp links, because the Org-babel way is much better and clearer to have that code in a block, rather than hiding it in the invisible part of of a link. Here is an early vote [1] for *not* removing shell and elisp links. Deprecation/documentation/scary warnings is fine with me, but I do use these kinds of links and I'd like to be able to continue using them. Thanks, Nick [1] and if necessary, I can vote often too :-), but I don't know if the vote early/vote often model would work here... ___ 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 wrote: Carsten Dominik carsten.domi...@gmail.com wrote: :-) Actually, in this specific area I had been thinking to removing or at least deprecating shell and elisp links, because the Org-babel way is much better and clearer to have that code in a block, rather than hiding it in the invisible part of of a link. Here is an early vote [1] for *not* removing shell and elisp links. Deprecation/documentation/scary warnings is fine with me, but I do use these kinds of links and I'd like to be able to continue using them. For my own understanding of what more I could do that I don't even think of right now, *if not indiscreet/private*, could you give a couple of applications of such links? 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, Pursuant to the below, I've created a new babel-safety branch of the repository. It includes two new commits, the first of which implements confirmation before *any* code block evaluation, adds the keybinds for code block evaluation, and adds a documentation for disassociating code block evaluation from C-c C-c. ,[1d0b2f48c7f4b12b07dcfff0b5c1d29cc2c863bb] | babel: evaluation of code blocks now requires confirmation | | * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to | control evaluation of code blocks, default value it t, meaning all | code block evaluation requires confirmation | | (org-babel-confirm-evaluate): function used to request confirmation | of code block evaluation from the user | | (org-babel-execute-src-block): this function is the single point of | entry for evaluation of code blocks (whether initiated through lob | call, through direct code block evaluation, or as part of file | exportation). Every time this function is called it will now | request confirmation from the user. The newly added | `org-confirm-babel-evaluate' variable can be used to configure this | behavior. | | * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block | evaluation behavior | | * lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings | for executing code blocks and for opening their results ` the second commit creates org-babel-load-languages, which can be used to enable or disable any babel language. ,[5f5f41a206ccef10b8ff49af8c689995d05da37c] | babel: `org-babel-load-languages' activates code blocks by language | | * lisp/org.el (org-babel-load-languages): this variable controls which | languages will be loaded by org-babel. It is customizable through | the customize interface. | | (org-babel-do-load-languages): load those languages in | org-babel-load-languages and disable those with nil cdr's ` While this variable works, and has a very nice customization widget interface, it is awkward to customize from a user's configuration file, this is because it relies on the defcustom :set function with which is it associated, and as far as I can tell, the only way to ensure that the set function is called, is to set this variable with something along the lines of the following in your configuration. --8---cut here---start-8--- (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (ruby . t) (python . nil) (R . t))) --8---cut here---end---8--- As of right now I can't think of a more natural way to implement such a variable -- suggestions welcom :). As I mentioned I'm keeping this is the babel-safety branch for now, as it *will* disrupt the configuration and experience of Babel users, and I've been hard on them already these past few weeks. Maybe this is best folded into main along with the version 7.0 release so that it will be accompanied with web-accessible documentation how to handle the incomparable changes. Thanks -- Eric Eric Schulte schulte.e...@gmail.com writes: Hi, Thanks for finding such a good compromises solution. This new plan looks great to me, specifics below Carsten Dominik carsten.domi...@gmail.com writes: Hi everyone, first of all, I think it is clear that I may have overreacted with the 6 point plan. But it is good that we are having this discussion. On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote: Hi Carsten, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module. This will not solve the problem fully, I think, because we also don't want that people who turn it on automatically commit to potentially dangerous operations. There is a lot of good stuff in Babel which has nothing to do with code evaluation. Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. This sounds like a good idea to me, and it should address Matt's desire for enabling minimal Org-mode installs. I would like this to default to t, so that new users can try out Org-babel without overmuch effort. Actually, following
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 schulte.e...@gmail.com writes: Hi, Thanks for finding such a good compromises solution. This new plan looks great to me, specifics below Carsten Dominik carsten.domi...@gmail.com writes: Hi everyone, first of all, I think it is clear that I may have overreacted with the 6 point plan. But it is good that we are having this discussion. On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote: Hi Carsten, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module. This will not solve the problem fully, I think, because we also don't want that people who turn it on automatically commit to potentially dangerous operations. There is a lot of good stuff in Babel which has nothing to do with code evaluation. Here is what I propose (several items are similar to what Eric proposes) 1. A new variable
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Sébastien Vauban wxhgmqzgw...@spammotel.com wrote: Nick Dokos wrote: Carsten Dominik carsten.domi...@gmail.com wrote: :-) Actually, in this specific area I had been thinking to removing or at least deprecating shell and elisp links, because the Org-babel way is much better and clearer to have that code in a block, rather than hiding it in the invisible part of of a link. Here is an early vote [1] for *not* removing shell and elisp links. Deprecation/documentation/scary warnings is fine with me, but I do use these kinds of links and I'd like to be able to continue using them. For my own understanding of what more I could do that I don't even think of right now, *if not indiscreet/private*, could you give a couple of applications of such links? Hi Seb, it's nothing spectacular: on the contrary, it's all the mundane things that I have various scripts for (either shell or elisp), e.g. munge with my jottings of the week and prepare a weekly report that is mailed to my manager and also exported to HTML for posterity - that's an elisp link. It's particularly things that I don't do often enough so I tend to forget what they are called, what arguments they take, etc. The links provide just enough documentation to jog my memory and a convenient way to launch the thing. I have a lot of these in many files: they tend to be very specific and so after a while the details slip away (e.g. the org file that describes all I know about a particular bug, might have a link to the bugzilla entry for the bug (an html link), email links, file links to data and a link to start a test run - this last is generally a shell link). Before org, for shell scripts, I would list my ~/bin directory and try to discern which of the many hundreds of scripts in there is the one that I need, and assuming that I would find it, I would then read the script to find what arguments it would need. Now, I visit an org file (one of a handful, organized by topic), read the link description and activate it. IOW, it could all be done in org-babel, but I started these a long time ago and I have accumulated so many of them, that converting would be a pain. In addition, they are spread out all over the place, so I would have to convert them one by one as I need them and there are so many possible places for Murphy's law to intrude, that losing the capability would be cause for serious concern for me. Hence the preemptive vote :-) Cheers, Nick ___ 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 Eric, thanks for this. I would actually like to have a variable that will exclude evaluation from being added to the C-c C-c hook. I think users will understand better how to use this, and customizing it will work for sure. Explicitly removing it from the hook will only work after load time. We should also add (put 'org-confirm-babel-evaluate 'safe-local-variable (lambda (x) (eq x t))) After the definition of org-confirm-babel-evaluate to avoid that malicious code can change this setting through file variables. I have made a first draft of the security section in the manual, please take a look, add to it, and add a link to it from a good location in chapter 14. Cheers - Carsten On Jul 1, 2010, at 10:39 PM, Eric Schulte wrote: Hi, Pursuant to the below, I've created a new babel-safety branch of the repository. It includes two new commits, the first of which implements confirmation before *any* code block evaluation, adds the keybinds for code block evaluation, and adds a documentation for disassociating code block evaluation from C-c C-c. ,[1d0b2f48c7f4b12b07dcfff0b5c1d29cc2c863bb] | babel: evaluation of code blocks now requires confirmation | | * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to | control evaluation of code blocks, default value it t, meaning all | code block evaluation requires confirmation | | (org-babel-confirm-evaluate): function used to request confirmation | of code block evaluation from the user | | (org-babel-execute-src-block): this function is the single point of | entry for evaluation of code blocks (whether initiated through lob | call, through direct code block evaluation, or as part of file | exportation). Every time this function is called it will now | request confirmation from the user. The newly added | `org-confirm-babel-evaluate' variable can be used to configure this | behavior. | | * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block | evaluation behavior | | * lisp/babel/ob-keys.el (org-babel-key-bindings): adding keybindings | for executing code blocks and for opening their results ` the second commit creates org-babel-load-languages, which can be used to enable or disable any babel language. ,[5f5f41a206ccef10b8ff49af8c689995d05da37c] | babel: `org-babel-load-languages' activates code blocks by language | | * lisp/org.el (org-babel-load-languages): this variable controls which | languages will be loaded by org-babel. It is customizable through | the customize interface. | | (org-babel-do-load-languages): load those languages in | org-babel-load-languages and disable those with nil cdr's ` While this variable works, and has a very nice customization widget interface, it is awkward to customize from a user's configuration file, this is because it relies on the defcustom :set function with which is it associated, and as far as I can tell, the only way to ensure that the set function is called, is to set this variable with something along the lines of the following in your configuration. --8---cut here---start-8--- (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (ruby . t) (python . nil) (R . t))) --8---cut here---end---8--- As of right now I can't think of a more natural way to implement such a variable -- suggestions welcom :). As I mentioned I'm keeping this is the babel-safety branch for now, as it *will* disrupt the configuration and experience of Babel users, and I've been hard on them already these past few weeks. Maybe this is best folded into main along with the version 7.0 release so that it will be accompanied with web-accessible documentation how to handle the incomparable changes. Thanks -- Eric Eric Schulte schulte.e...@gmail.com writes: Hi, Thanks for finding such a good compromises solution. This new plan looks great to me, specifics below Carsten Dominik carsten.domi...@gmail.com writes: Hi everyone, first of all, I think it is clear that I may have overreacted with the 6 point plan. But it is good that we are having this discussion. On Jun 30, 2010, at 6:25 PM, Eric Schulte wrote: Hi Carsten, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module.
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 schulte.e...@gmail.com writes: 2) Babel will now be loaded by default along with the rest of Org- mode. This means that *everyone* currently using babel will need to change their Emacs config and remove the (require 'org-babel-int) and/or (require 'org-babel) lines. I would like to request that org-babel be made an optional module. I ask this as someone who uses org-babel regularly. Here are my reasons: - Org-babel adds rather specific and complex functionality to org- mode that those who use it as a simple outliner and todo manager do not require. (In other words, an option to turn it off might be nice for those who are worried about feature creep.) - Org-babel increases the risk of accidentally executing malicious or dangerous code when typing C-c C-c on a src block or exporting a file. Perhaps users should activate it only after they understand the risks. + For instance, I might write a blog post warning about the dangers of typing rm -rf ~/. If I put this between #+begin_src sh and #+end_src and unthinkingly hit C-c C-c, I would be in trouble. I believe this is the reason for the variables org-confirm-shell-link-function and org-confirm-elisp-link-function. + This is admitted a bit far-fetched as an example, as it would require one to have loaded ob-sh.el. But since elisp execution is activated by default, there remain opportunities for unwittingly executing code that is meant for other purposes (e.g., warnings, examples, etc.). Support for evaluating emacs-lisp code blocks is loaded by default. All other languages will need to be required explicitly. To conform to Emacs filename specifications all language require lines have been shortened from e.g. (require 'org-babel-sh) to (require 'ob-sh) When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Thanks! Matt
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Tue, Jun 29, 2010 at 11:03 PM, Eric Schulte schulte.e...@gmail.comwrote: - 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 Carsten, Thanks so much both for thinking this through. And thanks again, Eric, for your work in integrating org-babel into org-mode---including taking into account a humble user's concerns! :) Carsten Dominik carsten.domi...@gmail.com writes: Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. I think the default should be t, but I also like giving users the option of not loading org-babel. 2. As Eric proposes, a variable similar to org-confirm-shell-link- function This should by default query for confirmation on any org-babel code execution, and can be configured to shut up by people who know what they are doing. 3. Not loading emacs lisp evaluation by default. 4. A new key in the babel keymap for org-babel-execute-code-block, for example `C-c C-v e'. This should be documented as the default key for this operation. 5. Removing org-babel-execute-code-block from `C-c C-c'. Inclusion should be optional. 6. A section in the manual on code execution and associated security risks in Org mode. This is not only about babel, but also about org-eval, org-eval-light, shell links and elisp links. I have meant to write this section for a long time and would be willing to draft it. We could then refer to this section from a couple of places in the docs, without cluttering the docs with disclaimers. With safeguards with 2, 4, 5, and 6, would it be safe to skip #3 and load emacs-lisp evaluation by default? The primary risk right now is that C-c C-c is so easy to press. But if we change the keybinding and add a default warning, I believe the emacs-lisp evaluation would not pose undue dangers. After all, emacs already makes it easy to evaluate emacs-lisp code. IMO, other languages are a bit more dangerous, since they are out of context in an org-mode document---i.e., one is not necessarily as cautious about the pitfalls of executing shell commands, perl code, etc. as one is when using the command line or executing a script. Best, Matt ___ 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 30, 2010, at 2:53 PM, Matthew Lundin wrote: Hi Carsten, Thanks so much both for thinking this through. And thanks again, Eric, for your work in integrating org-babel into org-mode---including taking into account a humble user's concerns! :) Carsten Dominik carsten.domi...@gmail.com writes: Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. I think the default should be t, but I also like giving users the option of not loading org-babel. 2. As Eric proposes, a variable similar to org-confirm-shell-link- function This should by default query for confirmation on any org-babel code execution, and can be configured to shut up by people who know what they are doing. 3. Not loading emacs lisp evaluation by default. 4. A new key in the babel keymap for org-babel-execute-code-block, for example `C-c C-v e'. This should be documented as the default key for this operation. 5. Removing org-babel-execute-code-block from `C-c C-c'. Inclusion should be optional. 6. A section in the manual on code execution and associated security risks in Org mode. This is not only about babel, but also about org-eval, org-eval-light, shell links and elisp links. I have meant to write this section for a long time and would be willing to draft it. We could then refer to this section from a couple of places in the docs, without cluttering the docs with disclaimers. With safeguards with 2, 4, 5, and 6, would it be safe to skip #3 and load emacs-lisp evaluation by default? The primary risk right now is that C-c C-c is so easy to press. But if we change the keybinding and add a default warning, I believe the emacs-lisp evaluation would not pose undue dangers. I agree. After all, emacs already makes it easy to evaluate emacs-lisp code. IMO, other languages are a bit more dangerous, since they are out of context in an org-mode document---i.e., one is not necessarily as cautious about the pitfalls of executing shell commands, perl code, etc. as one is when using the command line or executing a script. Yes. Emacs Lisp is of course just as dangerous as the shell or anything else when it comes to malicious intent, but for running code by mistake it is much less dangerous than the shell, because usually elisp code deals with stuff inside Emacs and not so much on the system. - Carsten ___ 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, Matt, Scott, Carsten Dominik carsten.domi...@gmail.com writes: Hi Matt, hi Eric, Matt, thanks a lot for bringing this up. This is indeed a very important and serious issue. We need to address it. We need to step back and reconsider this carefully. Don't get me wrong, I absolutely think that Org Babel should give you enough rope to hang yourself. But we have to make sure that this will not happen to a happy and unsuspecting Org mode, or even an unsuspecting Emacs user who by chance opens a file with extension .org. I remember very well when first realized that shell links could really affect you badly. It scared me. You main proposal was to make Org Babel an optional module. This will not solve the problem fully, I think, because we also don't want that people who turn it on automatically commit to potentially dangerous operations. There is a lot of good stuff in Babel which has nothing to do with code evaluation. Here is what I propose (several items are similar to what Eric proposes) 1. A new variable org-turn-on-babel. We can discuss the default. If it is nil, org-babel should not be loaded. A default of t would be fine with me if we implement other measures listed below. This sounds like a good idea to me, and it should address Matt's desire for enabling minimal Org-mode installs. I would like this to default to t, so that new users can try out Org-babel without overmuch effort. 2. As Eric proposes, a variable similar to org-confirm-shell-link- function This should by default query for confirmation on any org-babel code execution, and can be configured to shut up by people who know what they are doing. Sounds good, I think this is a reasonable safety measure. 3. Not loading emacs lisp evaluation by default. I would push back on this point. Largely because we have now crossed the like to where it is impossible to play with a code block w/o first dropping down to your configuration files, and evaluating require statements. 4. A new key in the babel keymap for org-babel-execute-code-block, for example `C-c C-v e'. This should be documented as the default key for this operation. Hmm, I'm less enthusiastic about this point and point 5. I really like how 'C-c C-c' naturally does whatever-I-want given the context in which it's called, and I wouldn't want to lose that intuitiveness. Similarly 'C-c C-o' currently opens the results of a code block, I also find this very appealing as it allows for a uniform top-level interface across an Org-mode document, be it a code block or a link. Here are my reasons why I think leaving this keybinding is safe. 1) Unlike with shell/elisp links, the contents of code blocks is almost always visible right under the user's point. So it is less likely to evaluate something w/o having any idea what you are evaluating. 2) Adding a protection variable (e.g. org-confirm-babel-eval) means that the only users who could potentially evaluate a code block with a slip of the fingers would be users who have explicitly said that they want to be able to easily run code blocks without confirmation. 3) Emacs exposes a number of entry points into code evaluation. M-! allows users to run shell commands, C-M-x evaluate the elisp at point, and these have not caused problems in the past. 5. Removing org-babel-execute-code-block from `C-c C-c'. Inclusion should be optional. 6. A section in the manual on code execution and associated security risks in Org mode. This is not only about babel, but also about org-eval, org-eval-light, shell links and elisp links. I have meant to write this section for a long time and would be willing to draft it. We could then refer to this section from a couple of places in the docs, without cluttering the docs with disclaimers. This sounds like a very good idea. I'd be happy to help write such a section. The reason for 4 and 5 is that I believe Org-mode users are trained to blindly press `C-c C-c' whenever they want to update something at point. Matt's example of a blog post about `rm -rf' is a very realistic example for bad code being evaluated by mistake, not even due to malicious cations. I belive that a special key for this action would gove a good measure of protection. As I mentioned, I personally feel that an org-confirm-babel-eval variable is sufficient protection. I think it's safe to assume that if a user has explicitly customized that variable, then they know what they're doing and trust themselves to execute code responsibly. I think it's likely that the casual Org-babel user would never customize this variable, which seems to me entirely appropriate. This is what I think - please let me know if you think I am overdoing it. So to summarize, I think that the combination of (1), (2) and (6), should be sufficient to protect users from accidental code evaluation. Please let me
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Matt Lundin m...@imapmail.org writes: [...] When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Thanks! Matt Hi Matt, This should now be fixed. Thanks -- Eric ___ 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 schulte.e...@gmail.com Date: Wed, 30 Jun 2010 12:25:22 -0700 Subject: [PATCH 1/2] babel: evaluation of code blocks now requires confirmation * lisp/babel/ob.el (org-confirm-babel-evaluate): variable used to control evaluation of code blocks, default value it t, meaning all code block evaluation requires confirmation (org-babel-confirm-evaluate): function used to request confirmation of code block evaluation from the user (org-babel-execute-src-block-maybe): now requires explicit user confirmation before evaluating a code block (org-babel-open-src-block-result): now requires explicit user confirmation before evaluating a code block * lisp/org.el (org-ctrl-c-ctrl-c): added documentation of code block evaluation behavior --- lisp/babel/ob.el | 76 + lisp/org.el |7 - 2 files changed, 59 insertions(+), 24 deletions(-) diff --git a/lisp/babel/ob.el b/lisp/babel/ob.el index 6a42bcc..e2ffd67 100644 --- a/lisp/babel/ob.el +++ b/lisp/babel/ob.el @@ -61,6 +61,18 @@ (declare-function org-babel-ref-variables ob-ref (params)) (declare-function org-babel-ref-resolve-reference ob-ref (ref optional params)) +(defcustom org-confirm-babel-evaluate t + Require confirmation before interactively evaluating code +blocks in Org-mode buffers. The default value of this variable +is t, meaning confirmation is required for any code block +evaluation. This variable can be set to nil to inhibit any +future confirmation requests. + +Note disabling confirmation may result in accidental evaluation +of potentially harmful code. + :group 'org-babel + :type 'boolean) + (defvar org-babel-source-name-regexp ^[ \t]*#\\+\\(srcname\\|source\\|function\\):[ \t]* Regular expression used to match a source name line.) @@ -134,6 +146,19 @@ added to the header-arguments-alist. (org-babel-parse-inline-src-block-match) nil +(defun org-babel-confirm-evaluate (optional info) + Confirm that the user wishes to evaluate the code block +defined by INFO. This behavior can be suppressed by setting the +value of `org-confirm-babel-evaluate' to nil, in which case all +future interactive code block evaluations will proceed without +any confirmation from the user. + +Note disabling confirmation may result in accidental evaluation +of potentially harmful code. + (or (not org-confirm-babel-evaluate) + (yes-or-no-p (format Evaluate this%scode on your system? + (if info (format %s (nth 0 info)) ) + ;;;###autoload (defun org-babel-execute-src-block-maybe () Detect if this is context for a org-babel src-block and if so @@ -141,7 +166,10 @@ then run `org-babel-execute-src-block'. (interactive) (let ((info (org-babel-get-src-block-info))) (if info -(progn (org-babel-execute-src-block current-prefix-arg info) t) nil))) + (if (org-babel-confirm-evaluate info) + (progn (org-babel-execute-src-block current-prefix-arg info) t) + (error evaluation aborted)) + nil))) (add-hook 'org-ctrl-c-ctrl-c-hook 'org-babel-execute-src-block-maybe) @@ -379,28 +407,30 @@ argument RE-RUN the source-code block is evaluated even if results already exist. (interactive P) (when (org-babel-get-src-block-info) -(save-excursion - ;; go to the results, if there aren't any then run the block - (goto-char (or (and (not re-run) (org-babel-where-is-src-block-result)) - (progn (org-babel-execute-src-block) -(org-babel-where-is-src-block-result - (end-of-line 1) - (while (looking-at [\n\r\t\f ]) (forward-char 1)) - ;; open the results - (if (looking-at org-bracket-link-regexp) - ;; file results - (org-open-at-point) -(let ((results (org-babel-read-result))) - (flet ((echo-res (result) - (if (stringp result) result (format %S result -(pop-to-buffer (get-buffer-create org-babel-results)) -(delete-region (point-min) (point-max)) -(if (listp results) -;; table result -(insert (orgtbl-to-generic results '(:sep \t :fmt echo-res))) - ;; scalar result - (insert (echo-res results)) - t))) +(if (org-babel-confirm-evaluate) + (save-excursion + ;; go to the results, if there aren't any then run the block + (goto-char
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Eric Schulte schulte.e...@gmail.com writes: Matt Lundin m...@imapmail.org writes: [...] When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. This should now be fixed. Thanks. Everything was installed in the right place. - Matt ___ 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 schulte.e...@gmail.comwrote: Hi Rainer, I'm happy this was useful Rainer M Krug r.m.k...@gmail.com writes: On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte schulte.e...@gmail.com wrote: [...] *** Start babel #+begin_src emacs-lisp (org-babel-load-library-of-babel) #+end_src the above becomes #+begin_src emacs-lisp (org-babel-lob-ingest ~/path/to/org/contrib/babel/ library-of-babel.org) #+end_src I don't seem to need this line anymore - it is working without. Also, I don't remember why I put it in... The `org-babel-lob-ingest' function is used to load the source-code blocks defined in an Org-mode file into the global `org-babel-library-of-babel' variable. The functions defined in this variable can be called from any Org-mode file. This makes it possible to build a set of often-used generally applicable source-code blocks. The idea behind the library-of-babel.org file distributed with Org-mode is to share such functions throughout the entire Org-mode community. Thanks - now I understand it, Rainer Best -- Eric -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax:+27 - (0)86 516 2782 Fax:+49 - (0)321 2125 2244 email: 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
Hi Eric, Thanks again for all the work that you, Dan, and Tom have put into org-babel. I'm glad to see it become part of org-mode! Eric Schulte schulte.e...@gmail.com writes: 2) Babel will now be loaded by default along with the rest of Org-mode. This means that *everyone* currently using babel will need to change their Emacs config and remove the (require 'org-babel-int) and/or (require 'org-babel) lines. I would like to request that org-babel be made an optional module. I ask this as someone who uses org-babel regularly. Here are my reasons: - Org-babel adds rather specific and complex functionality to org-mode that those who use it as a simple outliner and todo manager do not require. (In other words, an option to turn it off might be nice for those who are worried about feature creep.) - Org-babel increases the risk of accidentally executing malicious or dangerous code when typing C-c C-c on a src block or exporting a file. Perhaps users should activate it only after they understand the risks. + For instance, I might write a blog post warning about the dangers of typing rm -rf ~/. If I put this between #+begin_src sh and #+end_src and unthinkingly hit C-c C-c, I would be in trouble. I believe this is the reason for the variables org-confirm-shell-link-function and org-confirm-elisp-link-function. + This is admitted a bit far-fetched as an example, as it would require one to have loaded ob-sh.el. But since elisp execution is activated by default, there remain opportunities for unwittingly executing code that is meant for other purposes (e.g., warnings, examples, etc.). Support for evaluating emacs-lisp code blocks is loaded by default. All other languages will need to be required explicitly. To conform to Emacs filename specifications all language require lines have been shortened from e.g. (require 'org-babel-sh) to (require 'ob-sh) When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Thanks! Matt ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Matt Lundin m...@imapmail.org wrote: When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? It's part of the git repository, so it should be present after you do a git pull. Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Not here: they end up in org-mode/lisp/babel. Nick versions: Org-mode version 6.36trans (release_6.36.448.gb954) GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2010-05-17 ___ 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 nicholas.do...@hp.com writes: Matt Lundin m...@imapmail.org wrote: When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? It's part of the git repository, so it should be present after you do a git pull. My apologies if my question wasn't clear. Yes, I can see the langs directory in the org-mode repo. The problem, however, is that make install does not copy the lang files to the target lispdir (in my case, /usr/local/share/emacs/site-lisp). I'm not sure about the conventional way to handle such installation in a Makefile, but it seems that the babel/langs/* files have to added to LISPF. Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Not here: they end up in org-mode/lisp/babel. What does org-mode represent here? Are you invoking make install to install to a target directory (lispdir) or are you simply leaving the compiled lisp files in place in the local org-mode repository? This section of the lisp file flattens out the lisp/babel hierarchy in the repo when copying to the target directory: --8---cut here---start-8--- install-lisp: $(LISPFILES) $(ELCFILES) if [ ! -d $(lispdir) ]; then $(MKDIR) $(lispdir); else true; fi ; $(CP) $(LISPFILES) $(lispdir) $(CP) $(ELCFILES) $(lispdir) --8---cut here---end---8--- Thanks, Matt ___ 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 m...@imapmail.org writes: Hi Eric, Thanks again for all the work that you, Dan, and Tom have put into org-babel. I'm glad to see it become part of org-mode! Eric Schulte schulte.e...@gmail.com writes: 2) Babel will now be loaded by default along with the rest of Org-mode. This means that *everyone* currently using babel will need to change their Emacs config and remove the (require 'org-babel-int) and/or (require 'org-babel) lines. I would like to request that org-babel be made an optional module. I ask this as someone who uses org-babel regularly. Here are my reasons: - Org-babel adds rather specific and complex functionality to org-mode that those who use it as a simple outliner and todo manager do not require. (In other words, an option to turn it off might be nice for those who are worried about feature creep.) I'm less struck by this point, as there are many features of Org-mode which I personally don't understand or use and I'm certainly some features the existence of which I am completely unaware. However as long as Babel doesn't significantly affect load time, I'd rather it be present in the background, to simplify it's use. - Org-babel increases the risk of accidentally executing malicious or dangerous code when typing C-c C-c on a src block or exporting a file. Perhaps users should activate it only after they understand the risks. + For instance, I might write a blog post warning about the dangers of typing rm -rf ~/. If I put this between #+begin_src sh and #+end_src and unthinkingly hit C-c C-c, I would be in trouble. I believe this is the reason for the variables org-confirm-shell-link-function and org-confirm-elisp-link-function. This to me is a much more motivating concern. With arbitrary code evaluation there is unlimited room for mayhem and destruction (both malicious and accidental), although anyone who works with code in any form is already exposed to such risks. + This is admitted a bit far-fetched as an example, as it would require one to have loaded ob-sh.el. But since elisp execution is activated by default, there remain opportunities for unwittingly executing code that is meant for other purposes (e.g., warnings, examples, etc.). No I don't think it's far fetched at all. I think any of the three following solutions (with a strong preference for the first) should address this problem. 1) My preferred solution would be to keep things largely as they are, only w/o emacs-lisp activated by default. That way there is no required configuration change for babel users (aside from having to add an 'ob-emacs-lisp require), and we address the issue of unintentional code execution -- anyone who has activated a language is presumably aware of what they are doing. Additionally this solution would retain some non-active Babel features like tangling. 2) We could add a new global environment variable along the lines of org-confirm-shell-link-function, say org-confirm-babel-execution or somesuch. This would be easy to implement, and would retain tangle like functionality but doesn't seem as conceptually clean as the above solution. 3) We package babel as a module, which would need to be explicitly required to be used. Support for evaluating emacs-lisp code blocks is loaded by default. All other languages will need to be required explicitly. To conform to Emacs filename specifications all language require lines have been shortened from e.g. (require 'org-babel-sh) to (require 'ob-sh) When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? Thanks for catching this, I never run make install and it didn't occur to me to think about the installed directory structure for languages. Currently the language-specific files occupy an odd role. They are not compiled or loaded by default because many of them have exotic/complex dependencies which most users will want to avoid -- e.g. slime. For this reason they must be explicitly required by users, and I think for the moment at least would need to be manually installed for a global instillation -- although I suppose we could update the Makefile to begin copying the un-compiled language files into the global lisp tree during instillation. At the same time the language files *are* part of Babel and Org-mode for things like FSF copyright attribution, so they live in the Org-mode lisp tree. Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Looks like it may be necessary to move ob-* files out of LISPF
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Matt Lundin m...@imapmail.org wrote: When I run make clean make make install I find that the language directory is not installed. Does the langs directory require a manual installation? It's part of the git repository, so it should be present after you do a git pull. My apologies if my question wasn't clear. Yes, I can see the langs directory in the org-mode repo. The problem, however, is that make install does not copy the lang files to the target lispdir (in my case, /usr/local/share/emacs/site-lisp). I'm not sure about the conventional way to handle such installation in a Makefile, but it seems that the babel/langs/* files have to added to LISPF. Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Not here: they end up in org-mode/lisp/babel. What does org-mode represent here? Are you invoking make install to install to a target directory (lispdir) or are you simply leaving the compiled lisp files in place in the local org-mode repository? This section of the lisp file flattens out the lisp/babel hierarchy in the repo when copying to the target directory: install-lisp: $(LISPFILES) $(ELCFILES) if [ ! -d $(lispdir) ]; then $(MKDIR) $(lispdir); else true; fi ; $(CP) $(LISPFILES) $(lispdir) $(CP) $(ELCFILES) $(lispdir) Ah, sorry for being dense: I forgot that I don't install - I run out of the git repository. Forgive my parochial view: there are indeed problems with the install target in the makefile. Nick ___ 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 all, Eric Schulte schulte.e...@gmail.com writes: Hi Matt, Thanks for raising the point about potentially dangerous code blocks. Matt Lundin m...@imapmail.org writes: [...] Also, with make install, the ob-* files are installed on the same level as the org-files, yet lines 108-114 in org.el indicate that they should be installed in a babel subdirectory. Looks like it may be necessary to move ob-* files out of LISPF and into their own new Makefile variable, so they can be handled separately and placed into a babel sub-directory. I *believe* I've successfully made this change to the Makefile. It looks like the babel files are now installed into their own babel subdirectory of the global lisp directory. I hardly believe this worked since it is the product of naive Makefile pattern matching (which has never worked for me in the past), however it appears to be compiling on my system. If someone who actually uses make install on their system (or is confident writing Makefiles) can confirm that this patch works then I'll apply it. Thanks -- Eric ___ 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 schulte.e...@gmail.com wrote: --=-=-= with attachment ;) I hardly believe this worked since it is the product of naive Makefile pattern matching (which has never worked for me in the past), however it appears to be compiling on my system. If someone who actually uses make install on their system (or is confident writing Makefiles) can confirm that this patch works then I'll apply it. Thanks -- Eric I took a quick look and I couldn't see where the babel/langs subdirectory is copied over to the install directory - did I miss it? Nick ___ 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
Nick Dokos nicholas.do...@hp.com writes: Eric Schulte schulte.e...@gmail.com wrote: --=-=-= with attachment ;) I hardly believe this worked since it is the product of naive Makefile pattern matching (which has never worked for me in the past), however it appears to be compiling on my system. If someone who actually uses make install on their system (or is confident writing Makefiles) can confirm that this patch works then I'll apply it. Thanks -- Eric I took a quick look and I couldn't see where the babel/langs subdirectory is copied over to the install directory - did I miss it? Ah, thanks, an undated patch is attached. Best -- Eric ___ 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
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=
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte schulte.e...@gmail.comwrote: Hi Rainer, Hi Eric First I'll give some expanded instructions in the hopes of helping out anyone else affected by my lack of good instructions in the announcement email. Then I'll provide a re-write of your config below as an example. Sounds perfect. Babel took the integration into Org-mode as an opportunity to do some much needed house cleaning. Most importantly we have cleared out unnecessary configuration variables -- which is great unless you already have these variables set. We have eliminated the two main internal lists of languages, namely - org-babel-interpreters and - org-babel-tangle-langs so any config lines which mention those variables, can/should be stripped out in their entirety. This includes any calls to the `org-babl-add-interpreter' function, whose sole purpose was to add languages to the org-babel-interpreters variable. OK - I understand that and it makes perfect sense. alright, so with those calls stripped out, we may still in some cases want to associate a file name extension with certain languages, for example we want all of our emacs-lisp files to end in a .el, we can do this will the `org-babel-tangle-lang-exts' variable. In general you shouldn't need to touch this as it already has defaults for most common languages, and if a language is not present in org-babel-tangle-langs, then babel will just use the language name, so for example a file of c code will have a .c extension by default, sh code will have a .sh extension ect... Perfect. You also mentioned shebang lines. This configuration now lives in header arguments. So the shebang for a single file can be set at the code block level, e.g. #+begin_src clojure :shebang #!/usr/bin/env clj (println with a shebang line, I can be run as a script!) #+end_src That's perfect - it adds much flexibility, and to do it via header arguments is absolutely perfect for me. note that whenever a file is tangled which includes a shebang line, org-babel will make the file executable, so there is good reason to only Wow - even better! add shebangs at the source-code level. However if you're sure that you want all of your code in some language (say shell scripts) to tangle out with shebang lines, then you can customize the default header arguments for that language, e.g. ;; ensure this variable is defined defined (unless (boundp 'org-babel-default-header-args:sh) (setq org-babel-default-header-args:sh '())) ;; add a default shebang header argument (add-to-list 'org-babel-default-header-args:sh '(:shebang . #!/bin/bash)) Good to know, but in general I am perfectly happy without shebang lines. But there are cases, where they are necessary. The final change, is that to conform to Emacs guidelines, the prefix org-babel-* in all require lines, has been changed to ob-*, also, since Babel now loads by default with Org-mode you can remove any (require 'org-babel) or (require 'org-babel-init) that may by lying around your configuration. OK - understood. Whew! that was alot of writing for a /simplification/ of configuration. Well - but it made many things much clearer for me. It is often more difficult to explain the changes which need to be made then to explain to a new user how it should be done. Hopefully the example of your configuration below will be a more succinct demonstration of the needed transformations. Rainer M Krug r.m.k...@gmail.com writes: Hi First of all thanks for integrating Org-babel into Org-mode. But for the less fluent elisp and org-mode users, I am slightly confused in the changes necessary on my side. I have the following in my emacs.org file: #+begin_src emacs-lisp (require 'org-babel-R) ;; requires R and ess-mode ;; (require 'org-babel-ruby) ;; requires ruby, irb, ruby-mode, and inf-ruby (require 'org-babel-python);; requires python, and python-mode ;; (require 'org-babel-clojure) ;; requires clojure, clojure-mode, swank-clojure and slime #+end_src the above becomes #+begin_src emacs-lisp (require 'ob-R) ;; (require 'ob-ruby) (require 'ob-python) ;; (require 'ob-clojure) #+end_src OK - done. *** Start babel #+begin_src emacs-lisp (org-babel-load-library-of-babel) #+end_src the above becomes #+begin_src emacs-lisp (org-babel-lob-ingest ~/path/to/org/contrib/babel/library-of-babel.org) #+end_src I don't seem to need this line anymore - it is working without. Also, I don't remember why I put it in... *** Customization of sh set shebang for sh script to #!/bin/bash and exclude additional comments (t) #+begin_src emacs-lisp (setq org-babel-tangle-langs (cons '(sh sh #!/bin/bash t) (remove-if (lambda (el) (string= (car el) sh)) org-babel-tangle-langs))) #+end_src #+begin_src emacs-lisp ;; ensure this
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Rainer M Krug r.m.k...@gmail.com writes: Just one additional question: When I go on the menu to Org -- Documentation -- Info Documentation, I still get the info help from version 6.21b, although I installed the version from git, and under Org -- Documentation -- Show Version it gives me Org-mode version 6.36trans (release_6.36.408.g7f21f). Can I change this somehow? It seems that the Info Documentation is the one which is part of emacs. That depends on your Emacs installation specifics. In short, the problem is that the directory containing the older Org documentation comes first in `Info-directory-list'. Reading the docstrings for this variable as well as `Info-default-directory-list' should give you enough information to come up with a solution suitable for your configuration. HTH, Štěpán ___ 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 step...@gmail.com wrote: Rainer M Krug r.m.k...@gmail.com writes: Just one additional question: When I go on the menu to Org -- Documentation -- Info Documentation, I still get the info help from version 6.21b, although I installed the version from git, and under Org -- Documentation -- Show Version it gives me Org-mode version 6.36trans (release_6.36.408.g7f21f). Can I change this somehow? It seems that the Info Documentation is the one which is part of emacs. That depends on your Emacs installation specifics. In short, the problem is that the directory containing the older Org documentation comes first in `Info-directory-list'. Reading the docstrings for this variable as well as `Info-default-directory-list' should give you enough information to come up with a solution suitable for your configuration. Thanks - I think I just have to add the directory in which the info files reside from the currently used org mode. Am I correct in assuming that is ~/.emacs.d/org-mode/doc ? HTH, Štěpán -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax:+27 - (0)86 516 2782 Fax:+49 - (0)321 2125 2244 email: 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 r.m.k...@gmail.com writes: On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec step...@gmail.com wrote: Rainer M Krug r.m.k...@gmail.com writes: Just one additional question: When I go on the menu to Org -- Documentation -- Info Documentation, I still get the info help from version 6.21b, although I installed the version from git, and under Org -- Documentation -- Show Version it gives me Org-mode version 6.36trans (release_6.36.408.g7f21f). Can I change this somehow? It seems that the Info Documentation is the one which is part of emacs. That depends on your Emacs installation specifics. In short, the problem is that the directory containing the older Org documentation comes first in `Info-directory-list'. Reading the docstrings for this variable as well as `Info-default-directory-list' should give you enough information to come up with a solution suitable for your configuration. Thanks - I think I just have to add the directory in which the info files reside from the currently used org mode. Am I correct in assuming that is ~/.emacs.d/org-mode/doc ? This is how I did it. It requires an emacs restart to pick up the new directory. http://doc.norang.ca/org-mode.html#InfoDocumentation -Bernt ___ 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 be...@norang.ca Rainer M Krug r.m.k...@gmail.com writes: On Mon, Jun 28, 2010 at 1:53 PM, Štěpán Němec step...@gmail.com wrote: Rainer M Krug r.m.k...@gmail.com writes: Just one additional question: When I go on the menu to Org -- Documentation -- Info Documentation, I still get the info help from version 6.21b, although I installed the version from git, and under Org -- Documentation -- Show Version it gives me Org-mode version 6.36trans (release_6.36.408.g7f21f). Can I change this somehow? It seems that the Info Documentation is the one which is part of emacs. That depends on your Emacs installation specifics. In short, the problem is that the directory containing the older Org documentation comes first in `Info-directory-list'. Reading the docstrings for this variable as well as `Info-default-directory-list' should give you enough information to come up with a solution suitable for your configuration. Thanks - I think I just have to add the directory in which the info files reside from the currently used org mode. Am I correct in assuming that is ~/.emacs.d/org-mode/doc ? This is how I did it. It requires an emacs restart to pick up the new directory. http://doc.norang.ca/org-mode.html#InfoDocumentation Thanks - that is adding the path to the variable Info-default-directory-list It is working now: I updated my org-mode directory with the following script: 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 r.m.k...@gmail.com 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 be...@norang.ca Rainer M Krug r.m.k...@gmail.com 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
Re: [Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Hi Rainer, I'm happy this was useful Rainer M Krug r.m.k...@gmail.com writes: On Fri, Jun 25, 2010 at 5:37 PM, Eric Schulte schulte.e...@gmail.comwrote: [...] *** 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
Eric Schulte schulte.e...@gmail.com writes: Hi Rainer, First I'll give some expanded instructions in the hopes of helping out anyone else affected by my lack of good instructions in the announcement email. Then I'll provide a re-write of your config below as an example. Babel took the integration into Org-mode as an opportunity to do some much needed house cleaning. Most importantly we have cleared out unnecessary configuration variables -- which is great unless you already have these variables set. We have eliminated the two main internal lists of languages, namely - org-babel-interpreters and - org-babel-tangle-langs so any config lines which mention those variables, can/should be stripped out in their entirety. This includes any calls to the `org-babl-add-interpreter' function, whose sole purpose was to add languages to the org-babel-interpreters variable. alright, so with those calls stripped out, we may still in some cases want to associate a file name extension with certain languages, for example we want all of our emacs-lisp files to end in a .el, we can do this will the `org-babel-tangle-lang-exts' variable. In general you shouldn't need to touch this as it already has defaults for most common languages, and if a language is not present in org-babel-tangle-langs, then babel will just use the language name, so for example a file of c code will have a .c extension by default, sh code will have a .sh extension ect... You also mentioned shebang lines. This configuration now lives in header arguments. So the shebang for a single file can be set at the code block level, e.g. #+begin_src clojure :shebang #!/usr/bin/env clj (println with a shebang line, I can be run as a script!) #+end_src note that whenever a file is tangled which includes a shebang line, org-babel will make the file executable, so there is good reason to only add shebangs at the source-code level. However if you're sure that you want all of your code in some language (say shell scripts) to tangle out with shebang lines, then you can customize the default header arguments for that language, e.g. ;; ensure this variable is defined defined (unless (boundp 'org-babel-default-header-args:sh) (setq org-babel-default-header-args:sh '())) ;; add a default shebang header argument (add-to-list 'org-babel-default-header-args:sh '(:shebang . #!/bin/bash)) The final change, is that to conform to Emacs guidelines, the prefix org-babel-* in all require lines, has been changed to ob-*, also, since Babel now loads by default with Org-mode you can remove any (require 'org-babel) or (require 'org-babel-init) that may by lying around your configuration. Whew! that was alot of writing for a /simplification/ of configuration. Hopefully the example of your configuration below will be a more succinct demonstration of the needed transformations. Rainer M Krug r.m.k...@gmail.com writes: Hi First of all thanks for integrating Org-babel into Org-mode. But for the less fluent elisp and org-mode users, I am slightly confused in the changes necessary on my side. I have the following in my emacs.org file: #+begin_src emacs-lisp (require 'org-babel-R) ;; requires R and ess-mode ;; (require 'org-babel-ruby) ;; requires ruby, irb, ruby-mode, and inf-ruby (require 'org-babel-python);; requires python, and python-mode ;; (require 'org-babel-clojure) ;; requires clojure, clojure-mode, swank-clojure and slime #+end_src the above becomes #+begin_src emacs-lisp (require 'ob-R) ;; (require 'ob-ruby) (require 'ob-python) ;; (require 'ob-clojure) #+end_src *** Start babel #+begin_src emacs-lisp (org-babel-load-library-of-babel) #+end_src the above becomes #+begin_src emacs-lisp (org-babel-lob-ingest ~/path/to/org/contrib/babel/library-of-babel.org) #+end_src *** Customization of sh set shebang for sh script to #!/bin/bash and exclude additional comments (t) #+begin_src emacs-lisp (setq org-babel-tangle-langs (cons '(sh sh #!/bin/bash t) (remove-if (lambda (el) (string= (car el) sh)) org-babel-tangle-langs))) #+end_src #+begin_src emacs-lisp ;; ensure this variable is defined defined (unless (boundp 'org-babel-default-header-args:sh) (setq org-babel-default-header-args:sh '())) ;; add a default shebang header argument (add-to-list 'org-babel-default-header-args:sh '(:shebang . #!/bin/bash)) #+end_src *** Customization of R set shebang for R script to and exclude additional comments (t) #+begin_src emacs-lisp (setq org-babel-tangle-langs (cons '(R R) (remove-if (lambda (el) (string= (car el) R)) org-babel-tangle-langs))) #+end_src the above can be omitted entirely If you've made it this far, then thanks for your patience, and please let me know if you run into any problems with the above. Best -- Eric How come some of your
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Štěpán Němec step...@gmail.com writes: [...] How come some of your rewrites above still use the `org-babel-' prefix? (As a side note, I don't see what Emacs guidelines suggest `ob-' is more appropriate than `org-babel-', and I would personally prefer to retain the latter -- it's much more descriptive.) Štěpán Hi Štěpán, The guidelines I mentioned (I believe) specify that all file names for emacs-lisp files which are part of Emacs must be unique in the first 6 or so characters. This is why all (require 'ob-*) lines (which must correspond to file names) now use ob-* instead of org-babel-*. Since I (like you) prefer the org-babel-* prefixes, those have been retained for all function and variable names. Hope this explains it, I'm certainly open to other naming suggestions. Best -- Eric ___ 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 schulte.e...@gmail.com writes: Štěpán Němec step...@gmail.com writes: [...] How come some of your rewrites above still use the `org-babel-' prefix? (As a side note, I don't see what Emacs guidelines suggest `ob-' is more appropriate than `org-babel-', and I would personally prefer to retain the latter -- it's much more descriptive.) Štěpán Hi Štěpán, The guidelines I mentioned (I believe) specify that all file names for emacs-lisp files which are part of Emacs must be unique in the first 6 or so characters. This is why all (require 'ob-*) lines (which must correspond to file names) now use ob-* instead of org-babel-*. Since I (like you) prefer the org-babel-* prefixes, those have been retained for all function and variable names. I see. Hm... could you provide some source for that? The only restriction on file names I can recall is this section from Appendix D of the Emacs Lisp Reference Manual: * Please keep the names of your Emacs Lisp source files to 13 characters or less. This way, if the files are compiled, the compiled files' names will be 14 characters or less, which is short enough to fit on all kinds of Unix systems. Is that perhaps what you meant? In any case, I see that the recommendation I quote above would make the file renaming necessary, too. (Also, I believe you actually did mention renaming *functions*, which created my confusion in the first place -- cf. the commit message of e0e4d76094f26 for example.) Hope this explains it, I'm certainly open to other naming suggestions. It would make a lot of sense to at least still begin the file names with `org' IMHO, if at all possible. Štěpán ___ 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 step...@gmail.com writes: Eric Schulte schulte.e...@gmail.com writes: Štěpán Němec step...@gmail.com writes: [...] How come some of your rewrites above still use the `org-babel-' prefix? (As a side note, I don't see what Emacs guidelines suggest `ob-' is more appropriate than `org-babel-', and I would personally prefer to retain the latter -- it's much more descriptive.) Štěpán Hi Štěpán, The guidelines I mentioned (I believe) specify that all file names for emacs-lisp files which are part of Emacs must be unique in the first 6 or so characters. This is why all (require 'ob-*) lines (which must correspond to file names) now use ob-* instead of org-babel-*. Since I (like you) prefer the org-babel-* prefixes, those have been retained for all function and variable names. I see. Hm... could you provide some source for that? The only restriction on file names I can recall is this section from Appendix D of the Emacs Lisp Reference Manual: * Please keep the names of your Emacs Lisp source files to 13 characters or less. This way, if the files are compiled, the compiled files' names will be 14 characters or less, which is short enough to fit on all kinds of Unix systems. Is that perhaps what you meant? In any case, I see that the recommendation I quote above would make the file renaming necessary, too. Maybe that is the ultimate source, this requirement came to me by way of a recommendation from Carsten when we first discussed merging babel into the Org-mode core. (Also, I believe you actually did mention renaming *functions*, which created my confusion in the first place -- cf. the commit message of e0e4d76094f26 for example.) my bad. Hope this explains it, I'm certainly open to other naming suggestions. It would make a lot of sense to at least still begin the file names with `org' IMHO, if at all possible. hmm, the longest (non-language-specific) file name is already 12 characters long, (length ob-tangle.el) ;; = 12 which doesn't give us much room to play around with. Looking at a couple of possible prefixes, and the related leftover characters for differentiating the *-tangle, *-comint, *-ref, etc... core babel files, yields the following | prefix | remaining characters | |--+--| | ob- |5 | | org-b- |2 | | orgb-|3 | | org-bbl- |0 | | bbl- |4 | | babel- |2 | #+TBLFM: $2='(sbe leftover (prefix $$1)) #+source: leftover #+begin_src emacs-lisp :var prefix= (- ;; length w/o .el (- 13 (length .el)) ;; length of prefix (length prefix)) #+end_src Personally, none of the above seem to be particularly superior to the current naming scheme, given the fact that we need to fit multiple files behind this prefix. -- Eric Štěpán ___ 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ěmecstep...@gmail.com writes: Eric Schulteschulte.e...@gmail.com writes: Štěpán Němecstep...@gmail.com writes: [...] How come some of your rewrites above still use the `org-babel-' prefix? (As a side note, I don't see what Emacs guidelines suggest `ob-' is more appropriate than `org-babel-', and I would personally prefer to retain the latter -- it's much more descriptive.) Štěpán [...] The only restriction on file names I can recall is this section from Appendix D of the Emacs Lisp Reference Manual: * Please keep the names of your Emacs Lisp source files to 13 characters or less. This way, if the files are compiled, the compiled files' names will be 14 characters or less, which is short enough to fit on all kinds of Unix systems. Are there any unix systems running emacs 22 (iirc org-mode doesn't support emacs 21 anymore) which have problems with long filenames? We're living in the 21st century, aren't we? [...] It would make a lot of sense to at least still begin the file names with `org' IMHO, if at all possible. hmm, the longest (non-language-specific) file name is already 12 characters long, (length ob-tangle.el) ;; = 12 which doesn't give us much room to play around with. Looking at a couple of possible prefixes, and the related leftover characters for differentiating the *-tangle, *-comint, *-ref, etc... core babel files, yields the following | prefix | remaining characters | |--+--| | ob- |5 | | org-b- |2 | | orgb-|3 | | org-bbl- |0 | | bbl- |4 | | babel- |2 | #+TBLFM: $2='(sbe leftover (prefix $$1)) #+source: leftover #+begin_src emacs-lisp :var prefix= (- ;; length w/o .el (- 13 (length .el)) ;; length of prefix (length prefix)) #+end_src Personally, none of the above seem to be particularly superior to the current naming scheme, given the fact that we need to fit multiple files behind this prefix. I think you have to add 2 to each of the numbers above. But the conclusion surely remains the same... Greetings, Stephan ___ 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, First I'll give some expanded instructions in the hopes of helping out anyone else affected by my lack of good instructions in the announcement email. Then I'll provide a re-write of your config below as an example. Babel took the integration into Org-mode as an opportunity to do some much needed house cleaning. Most importantly we have cleared out unnecessary configuration variables -- which is great unless you already have these variables set. We have eliminated the two main internal lists of languages, namely - org-babel-interpreters and - org-babel-tangle-langs so any config lines which mention those variables, can/should be stripped out in their entirety. This includes any calls to the `org-babl-add-interpreter' function, whose sole purpose was to add languages to the org-babel-interpreters variable. alright, so with those calls stripped out, we may still in some cases want to associate a file name extension with certain languages, for example we want all of our emacs-lisp files to end in a .el, we can do this will the `org-babel-tangle-lang-exts' variable. In general you shouldn't need to touch this as it already has defaults for most common languages, and if a language is not present in org-babel-tangle-langs, then babel will just use the language name, so for example a file of c code will have a .c extension by default, sh code will have a .sh extension ect... You also mentioned shebang lines. This configuration now lives in header arguments. So the shebang for a single file can be set at the code block level, e.g. #+begin_src clojure :shebang #!/usr/bin/env clj (println with a shebang line, I can be run as a script!) #+end_src note that whenever a file is tangled which includes a shebang line, org-babel will make the file executable, so there is good reason to only add shebangs at the source-code level. However if you're sure that you want all of your code in some language (say shell scripts) to tangle out with shebang lines, then you can customize the default header arguments for that language, e.g. ;; ensure this variable is defined defined (unless (boundp 'org-babel-default-header-args:sh) (setq org-babel-default-header-args:sh '())) ;; add a default shebang header argument (add-to-list 'org-babel-default-header-args:sh '(:shebang . #!/bin/bash)) The final change, is that to conform to Emacs guidelines, the prefix org-babel-* in all require lines, has been changed to ob-*, also, since Babel now loads by default with Org-mode you can remove any (require 'org-babel) or (require 'org-babel-init) that may by lying around your configuration. Whew! that was alot of writing for a /simplification/ of configuration. Hopefully the example of your configuration below will be a more succinct demonstration of the needed transformations. Rainer M Krug r.m.k...@gmail.com writes: Hi First of all thanks for integrating Org-babel into Org-mode. But for the less fluent elisp and org-mode users, I am slightly confused in the changes necessary on my side. I have the following in my emacs.org file: #+begin_src emacs-lisp (require 'org-babel-R) ;; requires R and ess-mode ;; (require 'org-babel-ruby) ;; requires ruby, irb, ruby-mode, and inf-ruby (require 'org-babel-python);; requires python, and python-mode ;; (require 'org-babel-clojure) ;; requires clojure, clojure-mode, swank-clojure and slime #+end_src the above becomes #+begin_src emacs-lisp (require 'ob-R) ;; (require 'ob-ruby) (require 'ob-python) ;; (require 'ob-clojure) #+end_src *** Start babel #+begin_src emacs-lisp (org-babel-load-library-of-babel) #+end_src the above becomes #+begin_src emacs-lisp (org-babel-lob-ingest ~/path/to/org/contrib/babel/library-of-babel.org) #+end_src *** Customization of sh set shebang for sh script to #!/bin/bash and exclude additional comments (t) #+begin_src emacs-lisp (setq org-babel-tangle-langs (cons '(sh sh #!/bin/bash t) (remove-if (lambda (el) (string= (car el) sh)) org-babel-tangle-langs))) #+end_src #+begin_src emacs-lisp ;; ensure this variable is defined defined (unless (boundp 'org-babel-default-header-args:sh) (setq org-babel-default-header-args:sh '())) ;; add a default shebang header argument (add-to-list 'org-babel-default-header-args:sh '(:shebang . #!/bin/bash)) #+end_src *** Customization of R set shebang for R script to and exclude additional comments (t) #+begin_src emacs-lisp (setq org-babel-tangle-langs (cons '(R R) (remove-if (lambda (el) (string= (car el) R)) org-babel-tangle-langs))) #+end_src the above can be omitted entirely If you've made it this far, then thanks for your patience, and please let me know if you run into any problems with the above. Best -- Eric which custimizes the shebang creation and the comments in the tangled file. Do I have to change any settings, and if yes, how? The
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 schulte.e...@gmail.comwrote: Hi Sébastien, Sébastien Vauban wxhgmqzgw...@spammotel.com writes: [...] For my own understanding, what's the status of `Org-babel-screen', for which I've never been able to understand completely all the differences with `sh' in `Org-babel'? I believe screen has more of a focus on sustained interaction with an interactive terminal, although to be honest I haven't really used it and can't say for sure. Benjamin Andresen, the author, may have a more satisfying answer for you. Second, a problem with the following code: ;; Org-babel needs to be told to recognize awk source code blocks and ;; how they should be tangled, which can be accomplished with the ;; following: (org-babel-add-interpreter awk) (add-to-list 'org-babel-tangle-langs '(awk awk)) (org-babel-add-interpreter fortran) (add-to-list 'org-babel-tangle-langs '(fortran f)) ;; ;; org-babel panics when trying to evaluate ruby code blocks because ;; ;; you don't have the required ruby executables available on your ;; ;; system. Probably the best way to deal with this is to remove ruby ;; ;; from the list of languages supported by babel: ;; (setq org-babel-interpreters (delete ruby org-babel-interpreters)) ;; make pre-built helper functions (`lob') available ;; (org-babel-load-library-of-babel) ;; mapping between languages (listings in LaTeX) and their major mode ;; (in Emacs) (setq org-src-lang-modes '((ocaml . tuareg) (elisp . emacs-lisp) ;; (Delphi . perl) (ditaa . artist) (asymptote . asy) (dot . fundamental))) ;; ) Neither org-babel-add-interpreter, neither its shorter version do exist now? Yes, thanks for bringing this up! I realized last night that I forgot to mention this in the announcement. We have simplified the handling of languages in Org-babel, in that the org-babel-interpreters and org-babel-tangle-langs variables have both been removed. Rather than keeping explicit lists of supported languages, Babel will now try to work with every language, and will only give up if it can't find a needed function (e.g. if there is no org-babel-execute:foo function defined then babel will give up on evaluating a foo code block). The only remaining language list is `org-babel-tangle-lang-exts' which can optionally be used to associate file extensions with language names, but is *not* required for evaluation or tangling. Given this, your configuration from above could be rewritten as --8---cut here---start-8--- ;; Org-babel now needs less hand-holding :) however it could be ;; useful to know extensions for some languages (add-to-list 'org-babel-tangle-lang-exts '(fortran . f)) ;; mapping between languages (listings in LaTeX) and their major mode ;; (in Emacs) (setq org-src-lang-modes '((ocaml . tuareg) (elisp . emacs-lisp) ;; (Delphi . perl) (ditaa . artist) (asymptote . asy) (dot . fundamental))) ;; ) --8---cut here---end---8--- Cheers -- Eric Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to
[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 Sébastien, Sébastien Vauban wxhgmqzgw...@spammotel.com writes: [...] For my own understanding, what's the status of `Org-babel-screen', for which I've never been able to understand completely all the differences with `sh' in `Org-babel'? I believe screen has more of a focus on sustained interaction with an interactive terminal, although to be honest I haven't really used it and can't say for sure. Benjamin Andresen, the author, may have a more satisfying answer for you. Second, a problem with the following code: ;; Org-babel needs to be told to recognize awk source code blocks and ;; how they should be tangled, which can be accomplished with the ;; following: (org-babel-add-interpreter awk) (add-to-list 'org-babel-tangle-langs '(awk awk)) (org-babel-add-interpreter fortran) (add-to-list 'org-babel-tangle-langs '(fortran f)) ;; ;; org-babel panics when trying to evaluate ruby code blocks because ;; ;; you don't have the required ruby executables available on your ;; ;; system. Probably the best way to deal with this is to remove ruby ;; ;; from the list of languages supported by babel: ;; (setq org-babel-interpreters (delete ruby org-babel-interpreters)) ;; make pre-built helper functions (`lob') available ;; (org-babel-load-library-of-babel) ;; mapping between languages (listings in LaTeX) and their major mode ;; (in Emacs) (setq org-src-lang-modes '((ocaml . tuareg) (elisp . emacs-lisp) ;; (Delphi . perl) (ditaa . artist) (asymptote . asy) (dot . fundamental))) ;; ) Neither org-babel-add-interpreter, neither its shorter version do exist now? Yes, thanks for bringing this up! I realized last night that I forgot to mention this in the announcement. We have simplified the handling of languages in Org-babel, in that the org-babel-interpreters and org-babel-tangle-langs variables have both been removed. Rather than keeping explicit lists of supported languages, Babel will now try to work with every language, and will only give up if it can't find a needed function (e.g. if there is no org-babel-execute:foo function defined then babel will give up on evaluating a foo code block). The only remaining language list is `org-babel-tangle-lang-exts' which can optionally be used to associate file extensions with language names, but is *not* required for evaluation or tangling. Given this, your configuration from above could be rewritten as --8---cut here---start-8--- ;; Org-babel now needs less hand-holding :) however it could be ;; useful to know extensions for some languages (add-to-list 'org-babel-tangle-lang-exts '(fortran . f)) ;; mapping between languages (listings in LaTeX) and their major mode ;; (in Emacs) (setq org-src-lang-modes '((ocaml . tuareg) (elisp . emacs-lisp) ;; (Delphi . perl) (ditaa . artist) (asymptote . asy) (dot . fundamental))) ;; ) --8---cut here---end---8--- Cheers -- Eric Best regards, Seb ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [ANN] Org-babel integrated into Org-mode
Bernt Hansen be...@norang.ca 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
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 | f6 a| A33F7A0C-F974-4C7F-A4FD-1AAA6CF9C60E | #+srcname: map-nav(shortcut-definition-list=shortcut-definition-list) #+begin_src emacs-lisp (defun map-navigation-shortcuts(shortcut-def) (global-set-key (read-kbd-macro (second shortcut-def)) (lexical-let ((shortcut-def shortcut-def)) (lambda () (interactive) (org-id-goto (third shortcut-def)) (mapcar #'map-navigation-shortcuts shortcut-definition-list) This is the cool use a table to map keyboard shortcuts code that was given to me in this conversation: http://www.mail-archive.com/emacs-orgmode@gnu.org/msg24971.html I've verified that the above code works with org-babel outside of the main branch, at this commit: commit a3cc050a9675127f4f9fb85ba30cb5c0b4417cf8 Author: Eric Schulte schulte.e...@gmail.com Date: Fri Apr 30 13:03:38 2010 -0600 Any ideas? Should I try to find the exact commit where it starts failing? Thanks, --Nate ___ 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
