From mboxrd@z Thu Jan 1 00:00:00 1970 From: tsd@tsdye.com (Thomas S. Dye) Subject: Re: Best practices for literate programming [was: Latex export of tables] Date: Thu, 18 Apr 2013 09:42:38 -1000 Message-ID: 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 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1USujd-0005Hi-4V for emacs-orgmode@gnu.org; Thu, 18 Apr 2013 15:43:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1USujb-00046u-9N for emacs-orgmode@gnu.org; Thu, 18 Apr 2013 15:43:09 -0400 Received: from oproxy5-pub.bluehost.com ([67.222.38.55]:41191) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1USujb-00045g-0o for emacs-orgmode@gnu.org; Thu, 18 Apr 2013 15:43:07 -0400 In-Reply-To: <877gjzsrtt.fsf@pank.eu> (rasmus@gmx.us's message of "Thu, 18 Apr 2013 18:53:50 +0200") 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: Org-mode Aloha Rasmus, Rasmus writes: > The following message is a courtesy copy of an article > that has been posted to gmane.emacs.orgmode as well. > > > Thomas, > >>> Tom, do tell us more about what these habits are. >> >> The new exporter is really your friend. Where before I might choose to >> generate a LaTeX block, now I look to generate Org output and then count >> on the exporter to do the right thing on the way to pdf. >> >> The exporter's attribute system is very easy to use. The attributes you >> need to access are always right there. >> >> I've also come to rely on filters quite a bit. I use them for >> non-breaking spaces, the plus/minus symbol, and for the multiple >> citation commands used by biblatex (e.g., \parencites). There seems to >> be a move afoot to collect filters so they can be widely distributed. >> I'd like to see the filters go to the Library of Babel, but for >> reproducible research it is probably best to keep them with the source >> document so there is no doubt about the fidelity of filter code. > > 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. I suppose this depends on what is meant by "reproducible." My goal is to produce a compendium as defined by Gentleman and Lang (see Gentleman R, Lang DT (2004). "Statistical Analyses and Reproducible Research." Technical report, Bioconductor Project. URL http://www.bepress.com/bioconductor/paper2). I keep the init.el file as a babel source block with the reproducible document, so it can be tangled. I also have an editing setup in a babel source block that activates many of the same features handled by the init.el file, but also configures the new exporter to look for init.el (which might have a different name). The filters are all part of the Org document, too, and get pulled into the init.el file with noweb references. A compendium with this structure gets past the problem, often aired on the ML, that there is "something in my setup" that causes unexpected behavior. The Org setup is completely contained in the compendium. I am able to distribute the compendium, typically as a single document (sometimes with associated data files produced by an on-line service that can't be used programmatically), which I believe is a good step toward reproducibility. Of course, it leaves open the question of changes in the underlying software. This is a real problem. Org 8.0, with its new (and sweet) exporter has broken my first two compendia. Conceivably, changes in Emacs might break a compendium, as could changes in all the other software referenced by babel code blocks. Aaron Ecay seems to be on to a possible mechanism to take care of at least some of this. AFAICT, however, his solution doesn't change the utility of the compendium, which seems to me an integral part of the reproducibility equation. What do you think? > > 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). Some journals specify which LaTeX packages can or cannot be used. PLOS-One, for instance, doesn't use booktab tables, so a reproducible research document sent to them couldn't include your default setting. My sense of the publishing world is that it is sufficiently variable eventually to break almost any default you might hope to establish. Incidentally, I think this is an area ripe for growth within Org mode--additions to the Library of Babel that configure a compendium to produce LaTeX code that meets the requirements of particular publishing venues. It would be ideal to do something like <> and then, when the journal sends back your paper with a digital pink slip, change that to something like <> and send it off again. All the best, Tom -- T.S. Dye & Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com