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.

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))

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. This way there is no auto-tangling, committing, etc... just regular
version control on the source of the source.




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 <bzg@gnu.org> wrote:

> Rainer M Krug <Rainer@krugs.de> 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
>
>