Re: Best practices for literate programming [was: Latex export of tables]

[Aaron Ecay <aaronecay@gmail.com>]

Hi Rasmus,

2013ko apirilak 18an, Rasmus-ek idatzi zuen:
> I too rely heavily on filters and customizations.  I haven't been able
> to fully appreciate the asynchronous exporter yet.
> 
> For instance I set some defaults for tables, pictures, add lots of
> entities etc. in my init file, and I went as far as writing a separate
> init file just loading just the org stuff.  Now, this is clearly /not/
> a very reproducible way of doing this.
> 
> So I'm really interested in hearing or seeing implementation where the
> goal is reproducibility.  On one hand I can appreciate keeping Org
> close to a vanilla state.  On the other hand, I'd have to overwrite
> defaults every time (e.g. I /always/ want booktab tables).  I guess I
> could keep an emacs-lisp block in the top of the file specifying
> stuff, but it also seems kind of tedious (copy-pasting every time).
> (Perhaps this could be resolved by loading external files hosted
> somewhere accessible).

If your external org configuration file were kept under version control
(I’ll discuss git but the principle is general), then reproducibility
would be possible.  There are ways of embedding git hashes in LaTeX
documents (for one example:
http://thorehusfeldt.net/2011/05/13/including-git-revision-identifiers-in-latex/),
and of course org could help automate this.  Including the git hash of
the document itself, the config file, and org-mode’s own code (assuming
these are kept in 3 separate repos) should allow perfect reproducibility
(modulo incompatible changes in emacs, I guess).

It would be interesting for org to have an ability to reference files
not just by name, but by git revision.  So that you could do something
like (where 123456 is some git hash):
#+include: [[gitbare:/path/to/repo::123456:my-org-setup-file.org]]
and have org take care of checking out the proper revision and loading
the file in the usual way.  This syntax is already implemented, for
plain links, in contrib/lisp/org-git-link.el, so it is just a matter
of making #+include and friends understand links in addition to
filenames.

-- 
Aaron Ecay