Re: [babel] org-babel-load-file can't use properties drawers ?

[Dan Davison <davison@stats.ox.ac.uk>]

Julien Fantin <julien.fantin@gmail.com> writes:

> I've been using this init file to load my org-mode-contained emacs configuration  :
>
> ;;; init.el --- Where all the magic begins
> ;;
> ;; This file loads both
> ;; - Org-mode : http://orgmode.org/ and
> ;; - Org-babel: http://orgmode.org/worg/org-contrib/babel/org-babel.php#library-of-babel
> ;;
> ;; It then loads the rest of our Emacs initialization from Emacs lisp
> ;; embedded in literate Org-mode files.
> ;; Load up Org Mode and Org Babel for elisp embedded in Org Mode files
> (setq dotfiles-dir (file-name-directory (or (buffer-file-name) load-file-name)))
>
> (let* ((org-dir (expand-file-name
>                  "lisp" (expand-file-name
>                          "org-mode" (expand-file-name
>                                 "elisp" dotfiles-dir))))
>        (org-contrib-dir (expand-file-name
>                          "lisp" (expand-file-name
>                                  "contrib" (expand-file-name
>                                             ".." org-dir))))
>        (load-path (append (list org-dir org-contrib-dir)
>                           (or load-path nil))))
>   ;; load up Org-mode and Org-babel
>   (require 'org-install)
>   (require 'org-babel-init)
>   (require 'org-babel-emacs-lisp))
> ;; load up all literate org-mode files in this directory
> (mapc 'org-babel-load-file (directory-files dotfiles-dir t "\\.org$"))
> ;;; init.el ends here
>
> It's been working nicely until I tried to clean things up by setting some commonly used variables  in properties drawers,
> and access them from emacs-lisp src blocks.
>
> The following illustrates my intent, and will behave as expected with org-babel-execute-buffer, but fails when it is loaded
> by org-babel-load-file :
>
> * Configuration
> :PROPERTIES:
> :ELISP-DIR:~/emacs.d/elisp/
> :END:
>
> ** Load Path
> #+begin_src emacs-lisp 
> (add-to-list 'load-path (org-entry-get nil "ELISP-DIR" t))
> #+end_src
>
> From my understanding, orb-babel-load-file tangles then loads the file, losing the variables in the process.

Yes. Initially when I read your email I thought "hang on, why didn't
Eric implement org-babel-load-file using org-babel-execute-buffer?" But
I think (of course) there are good reasons -- for example I believe that
C-h f will be able to link back to the file in which a function was
defined, if it is loaded with load-file.

>
> I've been using this function to get the expected behaviour, but the default somewhat breaks expectations, don't you think
> ?
>  (defun
>         ba/org-babel-load-file (file) (with-temp-buffer (insert-file-contents
>         file) (org-mode) (org-babel-execute-buffer)))
>
> Or, is there a cleaner way to achieve this ?

Eric may have a better answer, but I think that your solution is
appropriate. In fact, perhaps you'd like to donate us your function to
become org-babel-execute-file? So that would lead towards a scheme of
emacs initialisation broken into two parts:

1. org files containing emacs-lisp blocks that you want to be load-file'd
2. org files that you want to be org-babel-execute-file'd 

Perhaps org philosophy suggests that it ought to be possible for those
to be subtrees rather than distinct files? In which case we'd need to be
able to refer to a particular subtree within a particular file.

Here's a half thought through idea which might be getting convoluted and
out of my depth, but I wonder whether there's an alternative involving
lisp evaluation tricks. Would it be possible to have a version of
org-babel-load-file that doesn't simply extract the elisp from the
blocks, but instead generates the elisp that *would* be evaluated if you
had done C-c C-c, and then instead of evaluating it, tangles it to a .el
file so that it can be load-file'd. In particular, :var references would
be resolved and their variables set in a let binding as they are
normally. And perhaps you could get that (org-entry-get nil "ELISP-DIR"
t) to be evaluated while in the org buffer using the comma operator
somehow?

Dan


>
> Regards,
> julien
>
> _______________________________________________
> 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