I was pleased to see my review of the recently republished Liturgy and Personality by Dietrich von Hildebrand (Hildebrand Press) in this month’s Touchstone. You can read the short review online here. If you are at all interested in the ways that worship shapes and forms us at the deepest level, I highly recommend this short but dense book.
I’m also very much looking forward to this year’s Hildebrand Project Summer Seminar. This year, the focus will be on beauty and the line-up of faculty looks quite good.
Last week I had the pleasure of going to a wonderful talk by Dr. Christopher Graney at Immaculata Classical Academy. Graney spoke about the controversy surrounding Galileo and the heliocentric model. His main point was that most people spin this controversy as a conflict between science and bible-thumping faith, while ignoring the numerous scientific arguments that opponents of Galileo made at the time. For example, out of twenty-two arguments presented by Galileo’s contemporary Johann Georg Locher, only two were theological. The others had to do with objections from empirical data such as the absence of any observed parallax in the stars, the incorrect predictions of where planets would be on Galileo’s model, the apparent size of stars in telescopes at the time, and the motion of projectiles. These scientific objections were not decisively overcome until much later with the discoveries of Kepler, Newton, Coriolis, and others.
I had always thought that the main battle lines at the time of the controversy were between the old Ptolemaic model and the new Copernican model. I learned last week, however, that the most supported model at the time was that of Tycho Brahe, which differed from the Ptolemaic model by having the planets (other than the Earth) revolve around the sun, while the Sun, Moon, and stars still revolved around the Earth. The model apparently had better accuracy than either of the alternatives at the time and avoided the difficulties that are introduced with a moving Earth.
After the talk, Graney gave an encouragement to all the students of Latin at this classical school. He pointed out that most people who are into science these days have no Latin, and most people who study Latin are into things like classical poetry. This leaves a big hole in the history of science where there are few qualified researchers and yet a good deal of interest and funding available.
In the last post, I gave a brief introduction to using Pandoc. There are a few plugins for Sublime Text that I have installed that make it much easier to use Pandoc. On any Sublime Text installation, the first plugin to add should be Package Control. This allows you to easily install more plugins from within Sublime Text with an easy-to-use interface. While there are many plugins out there geared toward Markdown in general and Pandoc in particular, these are the ones that I use:
- Markdown Editing
- This markdown plugin trumps all the others and provides a base color scheme that I really like.
- Academic Markdown
- This requires Markdown Editing and extends its features to include some of the things academics would be interested in, like highlighting for Pandoc’s version of citations and CriticMarkup.
- Just tell this plugin where your BibTeX file is and it will handle all your citation needs. I especially use the fuzzy filterable list of all my bibliography entries to add citations extremely quickly even when I only half remember a title or the name of an author.
- This does what it says with lots of reconfigurability and minimal overhead.
- Wrap Plus
- This hard wraps selections and best of all it intelligently handles markdown-style block quotes and lists. (As an added bonus it handles a variety of block comment styles in different programming languages.)
Also take a look at the little tweaks that I have added myself for Academic Markdown and creating footnotes with a consistent numbering scheme across multiple files.
Pandoc is a command line tool that transforms one text format (like Markdown or reStructuredText) into another (like HTML, PDF, or Word). I primarily use it to transform my markdown source files into pretty things like web pages or PDFs that are ready to be printed out. Pandoc is more suitable to my needs as an academic than other markdown tools because it allows for necessary extensions of markdown like footnotes, bibliographies, and tables without becoming too unwieldy. Pandoc’s template system also means that I have full control over my output—although the defaults are pretty good when I just want to spit something out in an unusual format.
After installing Pandoc, you can simply run it from a command line (like Terminal or iTerm in OSX or cmd.exe or Cygwin in Windows). The basic usage is simple:
pandoc -o myOutputFile.docx myInputFile.md
-o flag just means “output” and the filepath after it specifies the name of the file you want to create. Pandoc will automatically detect which format you want to go from and which format you want to output just by the file extensions you give it. In my example, I’m going from a markdown file to a word file.
So far so good, but what if you want to take advantage of those cool things like automatically formated bibliographic footnotes? Simply add the appropriate flags with the necessary information.
pandoc --csl=myChicagoDefault.csl --bibliography=myBibliography.bib -o myOutputFile.docx myInputFile.md
In this example the
--csl flag specifies a file with the CSL-style specification for how footnotes and bibliographic entries should be formated and the
--bibliography flag specifies a file containing my BibTeX database of bibliography information. You can get more information on my exact set up in this post. Other flags I often include are
--smart for transforming straight quotes into curly quotes and hyphens into dashes and
--chapters for making first level headers in markdown into chapters in my dissertation.
At this point it becomes somewhat unmanageable to type all these flags in every time you want to get a Word version of the essay you’ve been writing. Luckily, I rarely open up the command line for Pandoc. Instead, I just save the command I use together with all the flags as a “build system” in Sublime Text.
Here’s the build system that I use as a Gist:
Using this I just press
Ctrl+Shift+B and I get a menu with the various output formats. I just select one, using either the mouse or the arrow keys, and out pops a new version of the file that I have focused in Sublime. The new file has the same name as the markdown version except that the extension is different.
I’m really impressed with what Shawn Graham over at Electric Archeology is doing with the Sublime Zettelkasten plugin. He is using Pykwiki to create a static site from his local folder of markdown files so that he can host an open notebook. You should really go over and check it out.
Sascha Fast said that I should write up a blog post explaining why I find my association of notes through Git useful. Admittedly, I only use this kind of association rarely. When I do, however, it proves to be just what I need.
I tend to work on my notes in creative bursts during which my mind is deeply immersed in the material. While I am putting all the notes and citations from (e.g.) an article where they go, I’m also opening totally fresh topics and thinking about seemingly unrelated things. For example, thoughts about Socrates’s comments about the real self, the soul, and conversation in the Alcibiades, will make me think about something connected to Martin Buber and Gabriel Marcel. When I’m done with a burst I commit in Git.
Most of the time, I navigate around my notes by either:
- using the quick panel in Sublime because I know exactly where I want to go,
- using direct links between explicitly associated notes, or
- searching for words or citekeys because I know the general topic I am looking for.
But these ways of moving from one note to others will not capture the association between Socrates and Martin Buber—there is no citekey in the later note since the article I was reading had nothing to do with Martin Buber; there are no obvious key words to search between the two files; and the random inspiration during the burst did not cause me to explicitly associate the notes with a hard link. Nevertheless, a year later I start to see the deep pattern that initially led me to think of Martin Buber while reading about Socrates. When I had the original inspiration, my grasp of this underlying pattern was totally inchoate. But now, I’m starting to see many little ideas across years of reading form one big constellation. As I work on this, it is super helpful to pull up a list—in under ten keystrokes—of all the notes I edited when I was working on this particular sentence of my note on the Alcibiades.
Christian Tietze had this to say on Twitter:
Date-based IDs in the file name do the same but only upon creation—the tech hurdle for Git is high, though.
I wanted to point out that I think everyone should be using Git anyway if they are doing anything in plain text. With an appropriate plugin, there is really very little to learn (no need to get into the CLI or any advanced features for our purposes). I also want to point out that Christian is exactly right. With date-of-creation timestamps or date-of-modification timestamps, you only get one point at which to place this note near others. With Git, you get nearness based on each change—both to the starting note and to its “change neighbors.”
After telling someone that they should use definition lists, I noticed that I had ignored them in my papers because I was too lazy back then to set up a nice format in LaTeX. Definition lists are great for philosophers (especially analytic philosophers) because it provides a good semantic structure for defining a proposition or example. So I updated the source of my papers to reflect my own advice. A good example of this is in my paper “Why Molinism Does not Help with the Rollback Argument.” You can see the raw source of this paper here, the PDF output here, and the HTML output here.
To get the PDF output to style nicely, I added this to the header of the LaTeX template that I use for Pandoc:
To get the HTML output for this site to style nicely, I used this CSS:
Hope this helps!
Yesterday, I was helping another colleague get set up with markdown for his dissertation and realized that I did not have a convenient way of giving him the CSL file that I use to automagically format my footnotes according to the Chicago Manual of Style. So here is a link to this file posted to Gist.
CSL is an open standard that defines how bibliographic elements are put together (e.g. parentheses versus footnotes). You can use this with many tools, but I use it with Pandoc. To get it to work, you need to define two files when you run Pandoc:
- You need the
--bibliographyflag to point to a BibTeX file with your bibliographic information so that Pandoc knows which author wrote which book. (This is the format that BibDesk and JabRef save in automatically.)
- You need the
--cslflag to point to the CSL file so that Pandoc knows how you want things to look.
An example command might look like this:
pandoc --bibliography=~/Dropbox/mybib.bib --csl=~/Dropbox/chicago.csl -o test.html test.md
You can have multiple CSL files for different formats, say one for author–date and one for footnotes. Then, on a project-by-project basis you can easily switch between them without having to change your source document. The source will just contain a Pandoc citation that looks like this
[@gerson03 67] and it will get formatted differently based on which CSL you use.
TheClearHorizon asked an interesting question in a comment thread over at Zettelkasten.de about a particular advantage of Luhmann’s index card system. While responding to his post, I realized that there was a certain structural feature that I had reproduced using Git without reflecting that I had done this. I would like to make two points, first a theoretical point about the architecture of a Zettelkasten and second a practical point about using Git to achieve this.
There are different kinds of association between ideas, and the architecture of a note-taking system can be better or worse at capturing these connections. Luhmann’s Zettelkasten system is brilliant because it captures many types of association very efficiently. Each index card has an ID that looks something like this
143b/3c/2. The first number
143 stands for a particular topic, say Sartre. Letters indicate branching within that topic. So
143b may stand for Sartre > No Exit. A slash followed by a number stands for a continuation (which is necessary because of the physical size of the index cards). So
143b/3 would stand for the third index card of Satre > No Exit. (My apologies if this is not a strictly accurate representation of Luhmann’s actual system.)
The disadvantage of this system is that the numbers are rather cryptic. On an electronic version we have the space, so we can just write
Sartre > No Exit rather than
143b. We can still capture the two kinds of association between ideas that matter most: (i) explicit reference and (ii) hierarchical nesting. Subtly, however, we have just lost an important form of association: (iii) the sequential relationship between 142 and 143.
142 might stand for Drama and we would not immediately think to associate Drama and Sartre. They are associated in the numbering system because the person creating the cards first opened a new topic for Drama and then opened a new topic for Sartre. The two ideas are associated for the researcher because of the chronological nearness of the work.
One of the great advantages of working in a plain-text format like Markdown is that you can use powerful tools like Git rather than whatever your software happens to ship with. Many change-tracking features in software like Word or Dropbox happen automatically. Each time you save or make a change, the software keeps track of what you did. This is fine if all you want is to keep from loosing your work, and you can make Git work this way too. But there is a better way: make intentional commits with brief, descriptive messages that log what you have done at logical intervals in your work. For years, I have been doing this for all my writing as a matter of course.
Now the realization: I have also been using Git to get the same kind of association that I thought might be lost by switching from numbers to descriptive titles. Each time you make a commit in Git, you have a group of files that have been changed at the same time. They are “change neighbors” so to speak. With a Git plugin in Sublime Text, it takes only a few keystrokes to pull up a log of all the times a particular file has been changed. By selecting one of these commits, I can—within seconds—see all the “change neighbors” of this particular file at any stage of its development. In other words, I can easily see all the notes (whether I would later think to relate them or not) that I was working on at the same time as this note.
This method of association is actually more powerful that the association between
143 above. Those numbers were close to each other only because those top-level topics were created at the same time. Association through Git commits, however, established nearness each time the note is changed not just at creation.
So I have a colleague who is using the LaTeX template that I developed to go from Markdown to PDF using Pandoc and he wants to put his name and class information at the top of an essay. Pandoc expects metadata like this to be at the top of your markdown file in a YAML block like this:
--- author: Dan Sheffler title: Example Title class: PHI 735 semester: Fall 2015 ---
So how do we get this to render in the PDF via LaTeX? I used Pandoc’s conditional template tags to check and see if each piece of the metadata is there (that way you could leave something blank and it won’t choke). If a piece of the metadata is there, then it goes into the document on a new line with no paragraph indent.
\noindent $if(author)$$author$$endif$\\ $if(title)$$title$$endif$\\ $if(class)$$class$$endif$\\ $if(semester)$$semester$$endif$\\
Make sure you copy and paste this LaTeX bit into your
default.latex template somewhere below the
\begindocument command and above the
\doublespace command (if you are using the spacing package). If you wanted to extend this it would be simple to add another variable to both the YAML and the template with something like
When all is done, this should produce something at the top of the PDF that looks like this:
Hope this helps!