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

[Rasmus <rasmus@gmx.us>]

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.

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

–Rasmus

-- 
. . . The proofs are technical in nature and provides no real understanding.