The drawer, according to Kirk McElhearn, was a badly designed UI element. An optional display of additional information, the drawer extended out from the main window. McElhearn was not alone in despising the drawer, and it is clear that it is a UI element whose days are numbered. However, the absence of the drawer from TM2 has made clear to me just how good it was, if used appropriately. Indeed, TextMate’s drawer was IMHO one of the drawer’s finest implementations.

The project drawer allowed easy navigation through a directory of files. It has been replaced by a file browser sidebar. In some ways, the sidebar is more attractive than the drawer in that it has the same height as the main window. However, toggling the sidebar is, in my opinion, a disaster, in that it varies the size of the text window. When you show the sidebar, the application’s window remains fixed, but the text displayed within that window shrinks to accommodate it. Moreover, if you are working with a LaTeX document, or indeed any document that involves soft-wrapped long lines, then the text will shift to accommodate the presence of the sidebar. This means that a target in the text cannot be seen at a glance but must be re-identified. This is just the kind of cognitive drag that I do not want from my tools. Since the drawer extended out from the main window, the text in that window would remain fixed. That was what was so great about it.

Ironically, what I like about the drawer and despise about the sidebar was the basis of one of McElhearn’s complaints:

As I type this article in BBEdit, I have a document list in the drawer to the right of the main window. But if I close the drawer and expand the window to fill my screen, then click the drawer button, the drawer opens, but the main window doesn’t change size; I cannot see the drawer unless I resize the window. This is very bad. It is not an isolated case either: other applications have the same behavior, and still others don’t even display the drawer if the window is set to full screen. In such cases, you have to first resize the main window then display the drawer.

The passage, however, contains within it the key to our differences. Specifically, McElhearn has in mind a specific use case, one where the application’s window takes up the full screen. If the application’s window is full screen, then anything extending out from that window will be hidden from view. But not everyone uses their text editor in full screen mode. Indeed most TeXnicians prefer to have the editor on one half of the screen and the PDF output on the other.

I know, I know, with the iOSsification of Lion, full screen is in. But this was written in 2006 where the dominant Mac paradigm was multiple windows none of which were full screen. Full screen was for Windows. (I must confess to being a little puzzled by the current enthusiasm for all things full screen, I believe that there is a good productivity argument for the old Mac paradigm, but that is another post.)

Even so, the behavior of toggling the navigation sidebar is so disruptive, it would be best just to leave it open. That would be OK working on an iMac, but much less useful on a laptop where screen real estate needs to be managed.

This is not a plea for the drawer’s return. As a UI element, it has had its run. While I feel it did its job well (even if inconvenient in full screen mode), the drawer is dead. Long live the sidebar.

So why the antipathy? Partly because the professionalization of philosophy, its culture—what footnotes in scholarly articles are a manifestation of—rubs me wrong. Partly, because they are an excuse and can blind us to lazy writing. (Have a response to a referee’s objection? Just shove it in a footnote.) But mainly because I hit upon a proof of the impossibility of footnotes and have adopted it as my creed in writing. The proof assumes the availability of a means of citation other than the footnote, such as Harvard-style citations. The proof involves two distinctions and proceeds by cases. The content of a footnote is either interesting or uninteresting, relevant or irrelevant. If it is interesting and relevant, it belongs in the body of the text, if it is uninteresting and irrelevant it should be cut. The remaining two cases are interesting. Suppose the content of the proposed footnote is uninteresting and relevant. Relevance makes a strong case for inclusion in the body of the text. Being uninteresting is a reason for not including it, but it depends on the reason for its being uninteresting. Perhaps there is a problem with the presentation, or perhaps this is just the kind of tedious detail that is required for the more interesting material to come. Whatever’s the case, there’s no real justification for a footnote. That’s the easy way out. Finally, and tragically, there is the interesting and irrelevant. These need to be cut. You must steel your heart and murder your darlings as Sir Arthur Quiller-Couch famously advised. Why distract the reader from what can be a difficult and complex narrative with shiny and glittering asides? It is better to stay on point. And there are other, less distracting means of including such material. The namesake of this blog, excursus, is one such.

The result is a clean, modernist, distraction-free page, one not constantly demanding that you to lower your gaze in its presence. To be clear, I have adopted the proof as a creed in professional philosophical writing. Given the bad writing habits with which we philosophers have been inculcated, it is a hard creed to live by. It forces you to make hard decisions in light of what’s important in your writing. It thus enforces a kind of literary virtue. All of this is not to say that footnotes might reasonably hold sway in other regions of discourse (for example, in legal writing), or that they may be insightful, entertaining, that they might be the means of an authorial aside delivered in a stage whisper. Footnotes can be and have been a source of literary pleasure. In “Notes Towards a Mental Breakdown” J.G. Ballard writes a single sentence in which every word is footnoted. The narrative is spun out in the contents of the footnotes. The footnotes in David Foster Wallace’s Infinite Jest are wildly funny. Moreover play with footnotes is not confined to the postmodern novel. In a recent article in the New York Times, Alexandra Horowitz claims that an eighteenth century satirist composed an entire work of footnotes. (Found via @lucabaptista)

Horowitz is a footnote advocate. Read her case for footnotes and decide for yourself. While not blind to their literary pleasure, the footnotes in professional philosophy are a catch-all for laziness, self-deception, and self-aggrandizement (think of Kripke’s refutation of functionalism in a footnote or Stephen Neale’s three page footnote in his editorial introduction to the special issue of Mind devoted to the anniversary of Russell’s Theory of Descriptions).

Despite my opposition to her advocacy, at least within the confines of professional philosophy, Horowitz does raise an interesting and insightful point about the page-dependency of footnotes. Footnotes are footnotes partly by being located at the foot of a page. Without a page, there are no footnotes only endnotes (even if hyperlinked). Since footnotes are page-dependent in this way, the disappearance of pages on ebooks threatens the flourishing of footnotes this medium. The important point is that the page is a unit associated with a particular material medium, a dead tree book. But the contents of books are increasingly made available in media not constrained by pagination. This, I believe, is an important issue. Think about citation. If pagination isn’t marked, what form should citation take? I have yet to see a good design solution that combines the convenience of scrolling through text presented in a single continuous column with marked pagination. Oxford Scholarship Online is an example of an awkward design that combines the rigidity of fixed pagination with the fluidity of a webpage.

New technology has revealed that an important structural feature of books, the page considered as an abstract unit, is really just a contingent manifestation of its material constitution. It was easy to be blind to this in the absence of adequate alternatives (the scroll was an alternative, it just wasn’t adequate). As Nietzsche once insightfully remarked, “Our writing tools are also working on our thoughts”.

Branching for Academic Writers

Branching and merging is one of the great things about Git. You might wonder why branching is useful for writing. Three quick reasons:

1. First, it’s best practice to work on a development branch and periodically merge the results into the master branch. That way you can be confident about what’s on master and feel free to play around in the development branch.
2. Even with the master/development branching structure, sometimes you may not be so sure how to develop your material. It is easy and psychologically liberating to make another branch. If it works, merge into development (and eventually into master).
3. If you are basing a talk on a paper, it is useful to make a separate branch for the talk. Typically this involves streamlining. For example, you don’t need footnotes and references in a talk so these can go.

Git Cherry-Pick

If you are using branches, sometimes it can happen that you don’t want to merge all of the commits of one branch into another, just some. So suppose you are basing a talk on one of your papers and in rewriting you make a change that really should be in the paper. What to do?

Cherry pick.

git cherry-pick allows you to move just one commit from one branch to another (of course whether this is useful depends on your commits being atomic). Since Git has saved the entire history of your document, it can automagically determine how your text has been reorganized in protracted rewriting. With no work on your part, it will take the relevant hunk of text and correctly insert it.

Usage

Suppose you have the following branches: master, development, and talk. Remember we want to move a commit on the talk branch into development. First we need to get on the talk branch:

$ git checkout talk

Now we need to find the name of the commit by perusing the log:

$ git log
commit 493264994b3c88745d5cad979c34fca9200673fc
Author: PhilGeek <eli@markelikalderon.com>
Date:   Mon Sep 29 12:58:28 2010 +0100

    Added Anscombe quote

Most likely you only need an initial segment of the commit ID to uniquely identify the commit. With the commit ID in hand it’s time to cherry pick. First switch back to development:

$ git checkout development
$ git cherry-pick 4932649
Finished one chery-pick.
[master g734a9b] Added Anscombe quote
  1 file changed, 1 insertion (+), 1 deletion (-)

You’re done.

The spine and front cover have “Basic Writings” before “Martin Heidegger”, but this ordering is reversed in the two (sic!) interior title pages. The back cover refers to the book as “Basic Writings”, but that is clearly shorthand, and does not settle the matter one way or the other. Other mysteries abound. Is the subtitle “Revised and expanded edition” as it appears on the spine and front cover, or is it “from Being and Time (1927) to The Task of Thinking (1964)” as it appears in the title page. A colon mysteriously appears in the spine only to disappear, never to be seen again. Surely, punctuating titles is not under the purview of typesetters. But apparently, at Routledge, it is. This is the book production equivalent of a train wreck. I am loathe to refer to it in a bibliography, because I do not know what the book is called. How could it be that after close inspection, one is left with no idea what the title of a book is, or whether to alphabetize it under “B” or “M”.

$ git diff --color-words

followed by -S in the subsequent less pager.

Written by commandline (aka Thomas Gideon) at the request (behest?) of Cory Doctorow, Flahsbake was meant to address the problem of retaining an archival record of the production of digital texts. Cory Doctorow explains:

I was prompted to do this after discussions with several digital archivists who complained that, prior to the computerized era, writers produced a series complete drafts on the way to publications, complete with erasures, annotations, and so on. These are archival gold, since they illuminate the creative process in a way that often reveals the hidden stories behind the books we care about. By contrast, many writers produce only a single (or a few) digital files that are modified right up to publication time, without any real systematic records of the interim states between the first bit of composition and the final draft.

The problem is genuine, I have written about it before. Moreover, I agree that version control has a role to play in its solution. However, I have doubts about the utility of Flashbake. It’s simplicity is its virtue, but it is too simple. No commit messages? A record of ambient information is no real substitute. And Flahsbake’s users are supposed to be geeky enough to use a command line tool, but not geeky enough to master the following simplified workflow?:

$ git init
$ git add mynovel.txt
$ git commit -m "initial commit"
write write write
$ git commit -a -m "new commit message"

I am not sure I get it. Still, any version control is better than none. And maybe Flahsbake will function as a Git gateway technology. If you are interested in a less puzzled reaction to Flashbake see the Lifehacker article. But if you want to be a really nerdy writer, just use Git neat.

For art in printing is not the way
Of wild extravagance, weird display,
But rather the unobtrusive thrall
Of type that gives you no shock at all,
But draws your eye to the page with zest
And holds your mind to the thought expressed;
We must keep ourselves to this simple creed,
Type was made - and is meant - to READ!

Unfortunately, the source provided no citation.

Advanced features of LaTeX are best learned on a need to know basis. The LaTeX Companion can be daunting in its length. If you thought you needed to master all of that material before writing a LaTeX document you would never do so. So start simple, and learn how to do more advanced things as and when you need to.

Learn on a need to know basis, and when you do learn, hack. Don’t feel like you need to know whether the code will work before running it. The worst thing that will happen is that LaTeX will throw an error. LaTeX errors are instructive. Learn to love them.

These reflections arose today when I needed to do something which should have been simple. It was simple—once I learned how to do it. I was preparing a handout for my seminar. On the handout is a summary of the material that I presented on Cook Wilson and the nature of representation and notes on the ensuing discussion. It would be useful if these were visually distinguished.

My first thought was to use the color package. It has a command \colorbox that specifies the background color of a box. However, the results were suboptimal—small strips of white separate the colored lines. Disappointed, I thought, well, perhaps I can just color the relevant text with \textcolor. The discussion however could run for several paragraphs and it turns out that \textcolor chokes when it wraps multiple paragraphs. It was obvious to me, then, that there was no straightforward, out of the box, solution.

I decided to define a new environment, discussion:

\begin{discussion}
    
\end{discussion}

It requires the color package, and you need to define a color that will be used for the background. I used \definecolor{myblue}{rgb}{0.8,0.8,1}. (Readers of the wonderful Tikz Pgf manual will recognize this as the background color of the code blocks.) The strategy was simple—wrap a minipage in a box. The minipage environment defines, well, a small page:

\begin{minipage}[position]{width}
  
\end{minipage}

The minipage is wrapped in a box. Boxes are usually created by commands, but there is a box environment lrbox:

\begin{lrbox}{}
    
\end{lrbox}

The text within this environment is saved in the box <cmd>. Here is the discussion environment with all the bells and whistles.

\makeatletter\newenvironment{discussion}{%
   \noindent\begin{lrbox}{\@tempboxa}\begin{minipage}{\columnwidth}\setlength{\parindent}{1em}}{\end{minipage}\end{lrbox}%
   \colorbox{myblue}{\usebox{\@tempboxa}}
}\makeatother

Here’s the gist:

(Sorry for the duplication, but embedded gists are not showing up in some news readers.)

Two comments. The initial \noindent is required otherwise the entire box will be indented—which would be awkward since the width of the minipage is set to the width of the column. Another issue is that there is no paragraph indentation within the minipage environment. In effect, within that environment, LaTeX sets \parindent to 0. This, however, can be overridden with the \setlength command:

\setlength{\parindent}{1em}

Here is the result:

However, it’s the difference wherein the interest lies. Unlike obsessing about straight versus typographic quotes this is more straightforwardly a “semantic” issue about the significance of embedding material within quotations. But the actual usage of quotation is quite complex as anyone familiar with the recent philosophical literature on quotation will attest. Far more complex than the simple semantics implicit in the charge of rampant use/mention conflation. Personally I abhor the use of quotation marks for emphasis, but the my distaste for it is simply that, distaste. It’s vulgar and largely confined to cheap marketing.

Semantic drift is a reality. Don’t fear change. It will only result in needless rage.

Here is a screenshot illustrating the clean and then dirty state of the development branch.

Legislation that has not kept abreast of changing technology can make the choice difficult.

As a philosopher, I write research papers, drafts of which are distributed on the web as PDFs. Open access to evolving research is important, and I am committed to it. Since I want to give my work the best chance of being understood, I take the time to properly typeset the PDFs with XeLaTeX. There is a problem, however, with distributing PDFs over the web.

PDF files can contain font information in a way that is easily extractable from the file. While the licensing of some type foundries allow embedded fonts in PDFs, many (especially smaller type foundries) do not. Indeed the ones that did probably did so at Adobe’s urging when PDF distribution on the web was relatively small and so not that great of a risk.

I would like to support small type foundries by buying their fonts. There are some brilliant type designers out there, and they should be rewarded. Unfortunately, since the main thing I want these fonts for is for web distributed PDFs, I can’t do that without violating licensing restrictions. And that’s not support.

There are of course open source fonts. Some of them are fine pieces of work. But the choice is limited, and important design decisions should not be so constrained.

DRM is not the answer, as the recent history of music distribution online sadly reveals.

I don’t know how to resolve this problem. It is partly technological, partly, legal. But I thought I would highlight for other academics who distribute their work online.

Upon finishing this post, I came across this essay that has more information about the legal and technological obstacles with some discussion of potential solutions.

To install the GitHub bundle do the following:

$ sudo gem install git
$ cd ~/"Library/Application Support/TextMate/Bundles/"
$ git clone git://github.com/drnic/github-tmbundle.git "GitHub.tmbundle"
$ osascript -e 'tell app "TextMate" to reload bundles'

One of the great features of using TextMate to produce LaTeX documents is the TODO Bundle. The TODO Bundle let’s you to insert TODOs into comments and display these in a nicely formatted HTML window with links to the lines where the TODOs occurred.¹²

There are two limitations with the TODO Bundle, however, which made me look for an alternative (I still use the TODO Bundle, the alternative is merely a supplement):

1. While I try to proof my documents as much as I can onscreen, sometimes I need to proofread the hardcopy. Proofreading hardcopy is easier, and any incremental decrease in distraction is a real boon in proofreading since it requires a lot of attention.
2. Suppose you are collaborating on a LaTeX document and your collaborator isn’t using TextMate. Of course, they can still follow the TODOs in the comments, but it would be great if these could be made more salient.

The Solution

The solution to both of these problems is to use LaTeX to generate the TODO list for you. To do this, I used the index package. The index package reimplements the internal LaTeX index macros adding functionality. Of particular interest is its support for multiple indexes. Add the following to your preamble:

The first line loads the color package (since our TODOs will be colored to make them stand out from the surrounding text). The second line loads the index package. The next two lines:

\newindex{todo}{tod}{tnd}{TODO List} % start todo list
\newindex{fixme}{fix}{fnd}{FIXME List} % start fixme list

define two indexes. The \newindex command takes four arguments. These arguments correspond to the four pieces of information required to generate the index:

1. A short, unique tag that identifies the index.
2. The extension of the output file where the raw index information will be put by LaTeX.
3. The extension of the input file where the processed information created by MakeIndex will be stored to be read in later by LaTeX.
4. The title of the index.

The next two lines:

\newcommand{\todo}[1]{\textcolor{blue}{TODO: #1}\index[todo]{#1}} % macro for todo entries
\newcommand{\fixme}[1]{\textcolor{red}{FIXME: #1}\index[fixme]{#1}} % macro for fixme entries

define two new commands: \todo and fixme. To add a TODO simply add the following at the appropriate place in the text:

\todo{My TODO entry}

Similarly, for FIXMEs.

New commands can be added on a similar pattern. So, for example, suppose you want to add a CHANGE command. To do this, be sure to also define a new index:

\newindex{change}{chg}{cnd}{CHANGE List} % start change list
\newcommand{\change}[1]{\textcolor{green}{CHANGE: #1}\index[change]{#1}} % macro for change entries

Notice, that the commands are color coded, so be sure to change the color. Since the previous two commands were blue and red, I made the CHANGE command green.

If you want to generate a list of the TODOs, FIXMEs, etc, at the end of your document you need to use the \printindex command. This takes as an option the name of the index, so for TODOs and FIXMEs we would use:

\printindex[todo]
\printindex[change]

Before we typeset these indexes, we need to run the makeindex command. Suppose that the name of your LaTeX document is foo.tex. Then, in the terminal we would run:

$ makeindex -o foo.tnd foo.tod
$ makeindex -o foo.fnd foo.fix

The -o option is used to specify the name of the file generated by makeindex that is used, in turn, by LaTeX to typeset the index. Having run makeindex, if we now typeset the document, the indexes will be printed at the end of the document after a pagebreak. And if you are using the hyperref package, these will have links to the pages where the TODOs and FIXMEs are inserted. This step can be automated with a makefile such as Latexmk.pl.

Been working on some scripts to clean up the BibTeX file, to normalize cite keys, to render consistent author and journal names, to strip out local URLs, etc. So look forward to a new development branch and a directory of utilities.

That’s a sharp downturn in spam. I know that this is a little read technical blog by an academic, but there has been no corresponding downturn in traffic that would explain this. Could times be tough, not only for investment bankers, but for spammers as well?