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.