I’ve recently created some functions in emacs to make exporting notes, slides, and handouts somewhat easier. I do all this using org-mode. I figure there are at least a few other people who might find this workflow of interest so I though I would document it here (it will also serve as a document of how all this works in case I forget in the future). I want to be able to turn something like the following: ...
I spend a lot of time writing and editing. I use a text editor for this. I’ve written before on why I think text editors are the best means for writing and editing one can have. But part of why a text editor can be so important is that they tend to be extensible or configurable (or both)—you can fit the editor to your needs. I use emacs, which is perhaps the most configurable and extensible text editor there is. ...
Another summer, another excuse to tinker with my website. I’ve used pelican, a python static site generator, to run this website for nearly six years. It’s a great tool. But I dislike python dependency hell, and pelican is a bit slow. So I’ve looked elsewhere. Hugo is blazing fast, has a thriving community, decent templates, and a downloadable binary that you can get via homebrew. No more dependency management! Also important for me (as an emacs user), there is a great org-mode exporter—ox-hugo—that lets me easily generate the web content from an org-file. On the whole I’ve been very happy with the move. ...
Tools for writing using a computer fall into two broad camps. On the one side we have WYSIWIG word processing applications like Microsoft Word, Apple Pages, and Google Docs. They allow not only the typing of text but also real-time formatting and display. These applications are familiar to most, and are the dominant ones used in higher-ed today. They also tend to be expensive (or available only to those with institutional affiliation), suffer from issues of feature-bloat and unnecessary make-overs, and use proprietary non-human-readable file formats. ...
I find it generally preferable to keep information I use for teaching in a format that allows for different styles of presentation. I’ve written before about how one might keep a CV in a yaml document that outputs to a variety of different possible formats using pandoc. I also use a similar system for syllabi. The basic idea is to keep your syllabus in a yaml file and export it to html, pdf, or rtf using a makefile. The nice thing about this is that you can, e.g., hand out a nicely formatted PDF (or printout) of your syllabus at the beginning of the semester, and then keep a continually updated version on your course website as HTML, all without having to have multiple documents that you’re editing. You can find the basic template on Github and an example from my PHIL 101 class, also on Github. ...
I’m making some changes to the website over the next couple weeks. I’m moving all the teaching materials to their own websites (e.g. phil105.colinmclear.net). So please excuse any broken links you find in the meantime!
Suppose you want to keep a CV accessible in PDF, html, and perhaps other formats (e.g. docx). It’s a pain to do them all individually and keep them in sync. Here’s one way to avoid that issue, though it has a bit of initial work involved in setting everything up. What you want to do is keep your CV (or really anything of that ilk that you want to have available in multiple formats) in a YAML file and then use pandoc to convert the YAML file into whatever documents you need. I got the idea from looking at this template on Github. ...
I had to write a recommendation letter today and thought I’d use it as an excuse to write up a Pandoc template for Pandoc-LaTeX conversion. It generates a nice looking letter with letterhead (assuming you have a logo for it). It uses the newlfm package. The template is on github here. I got the idea from Matthew Miller’s post, and this discussion on texblog.org.
Academic writing typically requires writing something in drafts. Many drafts. Until recently there have been few ways of elegantly handling this. Often, one would need to title the current draft with the day’s date, then save this draft in a folder (named, e.g., “drafts” or “versions”), and do this every time one sits down to write. This works, in some ways. The data is there. The problem is that you quickly end up with a folder (or desktop’s) worth of files. These filenames have typically ridiculous and increasingly obscure titles (e.g. final-draft-final-revision\final-draft-04-2018.docx). And it is seldom clear, using this method, exactly what one did when, without actually opening a particular file and looking, or trying to remember when (and where) it was that one made the relevant change. ...
I’ve updated the website with (what I hope is) a cleaner look and a bit better navigation. Thanks go to DandyDev for developing a great bootstrap theme for Pelican. I’ll be continuing to tweak here and there so apologies if you find broken links or other infelicities.