[-- Attachment #1: Type: text/plain, Size: 581 bytes --] I see on the org-hacks.html page lots of interesting elisp code. If I wanted to use some of this (lots of this) it seems wrong to shove it all in my .emacs file. My first guess would be to put what I want into separate .el files, go to my .org file and do a load-file on the .el file of hacks. But I really loath doing something that's not "best practice." What's the best practice for enabling org-mode elisp hacks? And what if I want to use just one hack for one project? With usual elisp-ing you can simply evaluate region. Is that possible in conjunction with a .org file? LB [-- Attachment #2: Type: text/html, Size: 627 bytes --]
Lawrence Bottorff <galaxybeinglambda <at> gmail.com> writes: > > > I see on the org-hacks.html page lots of interesting elisp code. > If I wanted to use some of this (lots of this) it seems wrong to shove it > all in my .emacs file. My first guess would be to put what I want into > separate .el files, go to my .org file and do a load-file on the .el file > of hacks. But I really loath doing something that's not "best practice." > What's the best practice for enabling org-mode elisp hacks? And what if > I want to use just one hack for one project? With usual elisp-ing you can > simply evaluate region. Is that possible in conjunction with a .org file? Yes. But you might like to look at http://orgmode.org/worg/org-contrib/babel/intro.html#sec-8-2-1 which discusses "Emacs Initialization with Babel" for a comprehensive approach. For a single project, you can but a src_block in the master that loads whatever is needed or use a file local variables block to load up the requisites. See: Specifying File Variables in the emacs manual.
[-- Attachment #1: Type: text/plain, Size: 2435 bytes --] Hi, if I have a project based on org which require some special settings (not only in lisp) I use a babel block and execute it after loading the file. I did this e.g. to set my Java environment correct If I remember correctly, we discussed once an autoload feature for org-babel, but security concerns overruled that idea. If some autoload feature should ever land in the repro, one would have to make sure that the code can't be manipulated e.g. by an external editor. This would come close to creating org-babel-viruses ;) One possible idea which jumps just to my mind, how about a combination of a babel blocks and org-encrypt? Encrypted babel blocks with a certain tag could be considered save for execution immediately after the user authentication during loading a certain buffer. I guess most of the functionality (tag, encryption, block-execution) is there already, it just would need some glue to put it together and a hook into opening of org-mode files Hmmm..... I think I put Eric CC :) Other then this I have a .init.el which simply loads many other lisp files, one of them is init_org.el If you frighten that emacs start-up might be to much delayed you might want to check the daemon / emcasclient feature of emacs. All the best Torsten On 13 March 2013 23:38, Charles Berry <ccberry@ucsd.edu> wrote: > Lawrence Bottorff <galaxybeinglambda <at> gmail.com> writes: > > > > > > > > I see on the org-hacks.html page lots of interesting elisp code. > > > If I wanted to use some of this (lots of this) it seems wrong to shove it > > all in my .emacs file. My first guess would be to put what I want into > > separate .el files, go to my .org file and do a load-file on the .el file > > of hacks. But I really loath doing something that's not "best practice." > > What's the best practice for enabling org-mode elisp hacks? And what if > > I want to use just one hack for one project? With usual elisp-ing you can > > simply evaluate region. Is that possible in conjunction with a .org > file? > > > Yes. But you might like to look at > > http://orgmode.org/worg/org-contrib/babel/intro.html#sec-8-2-1 > > which discusses "Emacs Initialization with Babel" for a comprehensive > approach. > > For a single project, you can but a src_block in the master that loads > whatever is needed or use a file local variables block to load up the > requisites. > See: Specifying File Variables in the emacs manual. > > > > [-- Attachment #2: Type: text/html, Size: 3380 bytes --]
Torsten Wagner <torsten.wagner@gmail.com> writes: > Hi, > > if I have a project based on org which require some special settings (not > only in lisp) I use a babel block and execute it after loading the file. I > did this e.g. to set my Java environment correct > > If I remember correctly, we discussed once an autoload feature for > org-babel, but security concerns overruled that idea. > If some autoload feature should ever land in the repro, one would have to > make sure that the code can't be manipulated e.g. by an external editor. > This would come close to creating org-babel-viruses ;) > > One possible idea which jumps just to my mind, how about a combination of a > babel blocks and org-encrypt? > Encrypted babel blocks with a certain tag could be considered save for > execution immediately after the user authentication during loading a > certain buffer. I guess most of the functionality (tag, encryption, > block-execution) is there already, it just would need some glue to put it > together and a hook into opening of org-mode files > > Hmmm..... I think I put Eric CC :) > Sounds dangerous to me. I often place init.el files into sub-directories which require project specific customization. You may also want to look at (info "(elisp)Directory Local Variables") for adding setting based on the working directory. > > > Other then this I have a .init.el which simply loads many other lisp files, > one of them is init_org.el Maybe the methods used here [1] may provide inspiration. > > If you frighten that emacs start-up might be to much delayed you might > want to check the daemon / emcasclient feature of emacs. > Indeed, I've recently fully committed to this approach adding Emacs to the list of services started by my OS during boot (probably overkill for most users and configurations). Cheers, > > All the best > Torsten > > > > > On 13 March 2013 23:38, Charles Berry <ccberry@ucsd.edu> wrote: > >> Lawrence Bottorff <galaxybeinglambda <at> gmail.com> writes: >> >> > >> > >> >> > I see on the org-hacks.html page lots of interesting elisp code. >> >> > If I wanted to use some of this (lots of this) it seems wrong to shove it >> > all in my .emacs file. My first guess would be to put what I want into >> > separate .el files, go to my .org file and do a load-file on the .el file >> > of hacks. But I really loath doing something that's not "best practice." >> > What's the best practice for enabling org-mode elisp hacks? And what if >> > I want to use just one hack for one project? With usual elisp-ing you can >> > simply evaluate region. Is that possible in conjunction with a .org >> file? >> >> >> Yes. But you might like to look at >> >> http://orgmode.org/worg/org-contrib/babel/intro.html#sec-8-2-1 >> >> which discusses "Emacs Initialization with Babel" for a comprehensive >> approach. >> >> For a single project, you can but a src_block in the master that loads >> whatever is needed or use a file local variables block to load up the >> requisites. >> See: Specifying File Variables in the emacs manual. >> >> >> >> Footnotes: [1] http://github.com/eschulte/emacs24-starter-kit -- Eric Schulte http://cs.unm.edu/~eschulte
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --] Hi Eric, sorry for the last two spams. Believe it or not, I fell asleep last night, during typing an answer and somehow managed to send twice a message ;) People should not take there smartphones to bed. Sounds dangerous to me. I often place init.el files into > sub-directories which require project specific customization. You may > also want to look at (info "(elisp)Directory Local Variables") for > adding setting based on the working directory. > > Why does this sound dangerous. Encrypted babel blocks could not be modified and even not been read without user authentication. Furthermore, even if I use a org-file from someone else, I would have to authorize the execution by decryption of the block. Thus, its unlikely someone executes something by accident. Beside of the autostart, encrypted source code blocks might make sens too, if sensitive data might be part of the block. E.g. username and login credentials to login into a certain service. I do not want to hijack this thread. It was just an idea which sounded to me rather easy to implement, since the core features are all there already. Feel free, to set it on the crazy ideas list, if you feel that it is not a good idea ;) All the best Torsten [-- Attachment #2: Type: text/html, Size: 1730 bytes --]