John Kitchin writes: > What if we created a new directory in the repository called "org" which > contains these kinds of files? It would be analogous to the "lisp" > directory. I don't think we need to have both ob-R.org and ob-R.el in the > repository. I think that would be a very good idea for certain modules like your org-ref and ob-R I am working on. > > For example I wrote org-ref.org, and I load it like this in my init file > (the intention here is to only tangle the org file when it is newer than > the el file or if there is no el file. for some reason my memory says that > org-babel-load-file was not doing this but that may be a faulty memory). > > (if (or > (not (file-exists-p "org-ref.el")) > (< (float-time (nth 5 (file-attributes "org-ref.el"))) > (float-time (nth 5 (file-attributes "org-ref.org"))))) > (progn > (org-babel-tangle-file (expand-file-name "org-ref.org" > starter-kit-dir)) > (load-file (expand-file-name "org-ref.el" starter-kit-dir))) > (require 'org-ref)) Isn't the already existing org-babel-load-file doing exactly that? It is robust as it is used by many to load emacs.org, and it can also compile the file. > > I could see there being something like the lisp path for finding these > files, so that we could just do: > > (org-require 'org-ref) > > or the org-babel-load-file could be adapted to have a path to search for > files. OK - this sounds like a good approach. Thinking about it, I don't know if it is a good idea to change the installed files or add new ones, as this might (will?) cause access right problems. I would rather suggest to tangle the org file into a temporary file and then load it from there. Therefore, write access is not required for the installation (which is safer). So this would mean a rewrite of the org-babel-load-file function, or just add a third optional argument for the path of the .el and/or .elc file. > This way there is no auto-tangling, committing, etc... just regular > version control on the source of the source. That would be great, and I would convert the existing ob-R.el immediately. Cheers, Rainer > > > > > John > > ----------------------------------- > John Kitchin > Associate Professor > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > http://kitchingroup.cheme.cmu.edu > > > > On Thu, May 22, 2014 at 7:04 AM, Bastien wrote: > >> Rainer M Krug writes: >> >> > So the reason why I think it would be advantageous to have these files >> > in org does not lie with the programmer familiar with emacs-lisp, but >> > with somebody familiar with the other side. >> >> Sorry I was too terse in my previous answer: I completely agree with >> the goal you describe, but I don't think adding an .org source along >> the .el output (say e.g. ob-R.org and ob-R.el) will simplify my life >> as a maintainer: each time an ob-*.org file is changed we need to >> tangle it again... and this leads to auto-tangling, auto-committing >> considerations that I don't even want to start thinking about. >> >> -- >> Bastien >> >> -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D): +49 - (0)3 21 21 25 22 44 email: Rainer@krugs.de Skype: RMkrug PGP: 0x0F52F982