From: tsd@tsdye.com (Thomas S. Dye)
To: Rasmus <rasmus@gmx.us>
Cc: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: Best practices for literate programming [was: Latex export of tables]
Date: Thu, 18 Apr 2013 09:42:38 -1000 [thread overview]
Message-ID: <m1fvyn7hht.fsf@poto.westell.com> (raw)
In-Reply-To: <877gjzsrtt.fsf@pank.eu> (rasmus@gmx.us's message of "Thu, 18 Apr 2013 18:53:50 +0200")
Aloha Rasmus,
Rasmus <rasmus@gmx.us> 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 <<init-plos-one>> and
then, when the journal sends back your paper with a digital pink slip,
change that to something like <<init-nature>> 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
next prev parent reply other threads:[~2013-04-18 19:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-12 8:06 Latex export of tables Vikas Rawal
2013-04-14 23:29 ` Suvayu Ali
2013-04-16 11:56 ` Vikas Rawal
2013-04-16 13:13 ` Thomas Alexander Gerds
2013-04-16 17:39 ` Suvayu Ali
2013-04-16 20:07 ` Thomas S. Dye
2013-04-16 21:39 ` Suvayu Ali
2013-04-16 23:45 ` Thomas S. Dye
2013-04-17 10:21 ` Myles English
2013-04-16 22:10 ` Best practices for literate programming [was: Latex export of tables] Vikas Rawal
2013-04-17 0:06 ` Thomas S. Dye
2013-04-18 16:53 ` Rasmus
2013-04-18 17:59 ` Aaron Ecay
2013-04-18 18:25 ` Rasmus
2013-04-18 19:48 ` Achim Gratz
2013-04-18 19:42 ` Thomas S. Dye [this message]
2013-04-21 17:25 ` Rasmus Pank Roulund
2013-04-17 6:39 ` Suvayu Ali
2013-04-17 9:55 ` Rainer M. Krug
2013-04-17 10:10 ` Suvayu Ali
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1fvyn7hht.fsf@poto.westell.com \
--to=tsd@tsdye.com \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).