From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Best practices for literate programming [was: Latex export of tables] Date: Thu, 18 Apr 2013 13:59:28 -0400 Message-ID: <87r4i7ra7z.fsf@gmail.com> References: <20130412080600.GA18235@panahar> <20130414232953.GC11696@kuru.dyndns-at-home.com> <20130416115619.GA12405@panahar> <20130416173948.GC7402@kuru.dyndns-at-home.com> <20130416221022.GA7809@panahar> <877gjzsrtt.fsf@pank.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:54085) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USt7V-0003pk-SA for emacs-orgmode@gnu.org; Thu, 18 Apr 2013 13:59:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USt7S-00086r-6e for emacs-orgmode@gnu.org; Thu, 18 Apr 2013 13:59:41 -0400 Received: from mail-vb0-x22d.google.com ([2607:f8b0:400c:c02::22d]:64624) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USt7S-00086n-3L for emacs-orgmode@gnu.org; Thu, 18 Apr 2013 13:59:38 -0400 Received: by mail-vb0-f45.google.com with SMTP id w15so2758579vbf.32 for ; Thu, 18 Apr 2013 10:59:37 -0700 (PDT) In-Reply-To: <877gjzsrtt.fsf@pank.eu> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Rasmus Cc: emacs-orgmode@gnu.org, tsd@tsdye.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. >=20 > 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. >=20 > 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=E2=80=99ll discuss git but the principle is general), then reproducibili= ty 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-l= atex/), and of course org could help automate this. Including the git hash of the document itself, the config file, and org-mode=E2=80=99s own code (assu= ming 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. --=20 Aaron Ecay