The Solarized Writer’s Desktop

elegant_solarizedIn two more weeks, I end my post-heart-surgery medical leave and go back to doing what I love the most: being with students, teaching Chaucer and Shakespeare, and studying the literature and culture of medieval Britain.

It’s going to be a bit of a transition after three months of focusing on healing, so I’ve been spending my weekend doing a little preliminary “gearing up”, sort of preparing myself psychologically to head back to work, now that my body can actually handle it again.

Since part of my job involves doing some pretty heavy-duty research and writing, part of that prep has involved thinking about ways to work on those projects, especially the writing, with a high degree of focus. The computer is of course both a blessing and a curse in this regard: it’s a necessary tool, to be sure, but it can also be mightily discracting, not only in the sense of offering online diversions (social media, etc.) but visual clutter as well. Our operating systems and browsers seem to be increasingly geared to be platforms for selling us things, which means notifications and message-boxes of various kinds can really proliferate (Windows 10, for example, drives me insane in this regard). With multiple windows and toolbars, computer screens can become a cacaphony of clashing colors and notification sounds, none of which are particularly conducive to concentration.

So, being a bit of a nerdy sort, and also someone who cares about recycling older gadgets to reduce e-waste, I decided to resurrect an old desktop computer to use as a dedicated writing machine. The idea was to make the interface as distraction-free as possible, visually elegant, and conducive to long work sessions while minimizing eyestrain.

There are of course many “distraction free” writing apps out there that try to fill this kind of niche (such as WriteMonkey and Writeroom), but I’ve never found them quite right for me: as an academic, I rarely write only what springs spontaneously to mind: I’m constantly looking at previous drafts of what I’ve written, paging through electronic notes, PDF files of articles, etc. I generally also need some consistent information, such as the time (so I’m not missing my next class!), my to-do list, and basic weather information. I also wanted to capacity to play and control music right on the desktop, since that usually helps me tune out other ambient noise. Dedicated distraction-free writing tools accomplish their task my simply filling the entire screen and blocking out everything else; I wanted a solution that would not blocking things out, but rather byu displaying only what I want. So, my idea was to set up a system that would be as spare and distraction-free as possible without cutting me off from all the information and resources I generally need to manage while I write.

The result is what you see in the screenshot above. I’ll explain the techy bits of this below for anyone interested in duplicating or improving upon my efforts, but here’s what you’re looking at:

  • To create a very customizable system that runs quickly on an older computer, I used the Linux operating system, specifically the Xubuntu Linux flavor. Xubuntu is designed to be easy-to-use with a minimum of system resources while still being a fully-featured desktop environment. A similar arrangement should be possible with Windows and MacOS, using a somewhat different set of applications and tools.
  • To make the whole thing very eye-friendly, I based all the colors on the solarized color scheme developed by Ethan Schoonover. According to Schoonover:

Solarized is a sixteen color palette (eight monotones, eight accent colors) designed for use with terminal and gui applications. It has several unique properties. I designed this colorscheme with both precise CIELAB lightness relationships and a refined set of hues based on fixed color wheel relationships. It has been tested extensively in real world use on color calibrated displays (as well as uncalibrated/intentionally miscalibrated displays) and in a variety of lighting conditions.

I’ve found this scheme to be truly conducive to long periods of staring at a screen. My idea was to integrate all aspects of the desktop within this scheme, so that both the desktop and its various elements (wallpaper, window borders, application backgrounds, music player, system information display), as well as all the applications I need, share this same set of soothing colors.

  • I set up the system to use two monitors: one directly in front of the keyboard that’s entirely dedicated to the text I’m currently writing (this is the lefthand side of the screenshot above, which combines the images from both monitors). Just to my right, the second monitor is dor displaying system and other information (weather, time, music), and also for displaying and managing ancillary documents like notes, images, and PDF’s. This keeps the focus on the main text while also keeping all those other materials ready to hand.
  • As I’ve mentioned elsewhere on this blog, I love to write using plain-text tools, for a host of reasons that I explain here. My editor of choice for composing is an oldie-but-goody well-known to programmers but less so to writers, known as Vim. Vim is an old-school editor designed to run in a good old-fashioned terminal. There’s a definite learning-curve involved in using Vim, but it’s been worth it for me, as Vim has become about the fastest and most distraction-free tool for bare composition I’ve ever found. Since Vim runs in a terminal window, I simply have the lefthand monitor set up to display that single terminal window, made almost transparent, against the solarized background. This keeps the editor in the visual center of the monitor at all times, keeps my hands on the keyboard where they belong, and encourages a focus on what I’m writing.
  • The most prominent element on the righthand monitor consists of a system monitor tool called conky, set up to display the time, weather information, and basic system information.
  • To the left of the system information display, there’s a music player called ncmpcpp. This is another tool designed to run in an old-fashioned terminal. The beauty of this is that I can position a transparent terminal on the screen, and the music player becomes a background element of the desktop, always available but never in the way. Console applications also take up much less in the way of system resources than GUI apps, which helps to keep this older machine running smoothly.
  • The final element is my todo list, which I manage via a wonderful, elegant application by Gina Trapani called todo.txt. It’s basically a fancy way of keeping you todo list in a plain text file while still being able to manage it nicely, add and delete items, set contexts, etc. This is another console application, so it runs in another small, transparent terminal window right underneath the system information display.
  • Note management is a little more complex than simple composition, since it involves keeping track of many different small files at once (I keep my reading and thinking notes in small, plain-text files, organized into directories), so I use a more robust text editor for note management so I can easily switch between notes and have several note documents open at once. I accomplish this with the excellent Sublime Text. Note that Sublime Text (the other window in the right-hand part of the screenshop above) displays both my note documents in tabbed or tiled format, with a left-hand panel that shows the directory tree of my note directory, making everything readily accessible.

Those are the basics! Feel free to let me know what you think or suggest improvements. I’m also glad to work with the less-techy to set up similar arrangements of their own.

A few more details and resources:

Solarized Wallpaper:

Ncmpcpp documentation:

Solarized Numix theme for XFCE:

Conky Harmattan theme:


Plain Text Writing Lesson Five: Detangling Your Footnotes

Note: This is the fifth installment in a series of brief lessons on writing with plain text tools, such as basic text editors, Markdown syntax, and Pandoc. The lessons are designed with the nonmagic-wand-techy in mind, and are meant to
take about 5-10 minutes apiece to digest. If you’re unfamiliar with plain-text tools, I strongly recommend that you begin with the first lesson.

Footnote Foofaraw

Now that we’ve got the basics of plain-text writing, using markdown syntax, and invoking pandoc for formatting, let’s tackle one of the more complex bugbears of writing, especially for academic writers: footnotes.

If you’re accustomed to using a traditional word processor such as Word or LibreOffice Writer, you’re aware that the initial steps for including footnotes are pretty easy: select “footnote” from an “insert” menu or hit a keyboard shortcut, an auto-numbered note shows up at the bottom of the page, and you type happily away (or insert a note or placeholder code from a citation manager like Zotero or Endnote). Easy peasy.

As you’ve likely experienced if you’ve done a lot of heavily-footnoted writing, however, the problem isn’t about adding the notes initially; it’s about maintaining their continuity and formatting down the line. This isn’t such a big deal for shorter-form writing (like blog posts), but it can be a very big deal indeed for longer, more in-depth work, such as articles and book chapters. The problem is that those longer pieces tend to travel a great deal before reaching their final (published) destinations: they go back and forth between writers, peers, peer-reviewers, editors, publishers, etc. As with all of the complex coding that underlies a word processor document, irregularities have a way of creeping in as the document is continually emailed, opened under different platforms or tools, edited and modified, etc. This process can turn those easily-added footnotes into a nightmare: if you’ve ever had the problem of suddenly finding that your notes are out of sequence, or that the formatting has suddenly changed and no change in settings seems to bring them back into order, you know what I’m talking about.

Markdown and Pandoc to the Rescue, Again

What’s handy about Markdown here is basically the same principle outlined in lesson three: You keep your original document in a kind of “raw” format in which everything is consistent, and then use Pandoc to turn that universal format into any other format an editor, publisher, or friend might require. In this way, your preferred formatting, and the position and style of your footnotes, is essentially always preserved in a consistent state in your original markdown document. Changes can be made easily in that Markdown document without any possibility of unintentionally adding code that will affect your formatting down the line. In other words, using Markdown and Pandoc together can mean that you’ll never again need to tear your hair out when your notes go haywire.

The How-To Bit

There are two different ways to create footnotes using Markdown. The first is entirely native to Markdown, and is ideal for shorter-form writing for the web (i.e. blog posts). The second requires Pandoc, but is ideal for longer-form writing where maintaining the consistency of many footnotes is important.

The Markdown Way

To create a basic Markdown footnote, place your cursor where you want the footnote to appear in your text and start with an open bracket, followed by a caret, a footnote name or number, and a close bracket, like this:


Then, at the bottom of your main text, place the same sequence of characters again, followed by a colon, a space, and then the text of your note:

[^1]: Here is the text of the footnote.

In the final document, markdown will create a footnote at the bottom of your text that includes a link back to the in-text footnote marker, like this.1

This sort of footnote is excellent for web-oriented writing, since it assumes a contiguous text (i.e. no page breaks) and provides an easy way for readers to click back and forth between the superscript note indicators in the text and the notes themselves at the bottom.

However, it’s not difficult to see how these footnotes can become unwieldy with longer, more print-oriented documents with many footnotes. For one thing, creating them would mean constantly scrolling up and down your ever-expanding main text. For another, adding footnotes would mean manually re-numbering every note that comes after the newly added one. Talk about a pain!

Inline Footnotes in Pandoc

Luckily, we’re not stuck with native Markdown footnotes if we have Pandoc, which was introduced in Lesson Four.

Pandoc allows us to create inline footnotes, which are much more convenient for print-oriented writing that utilizes numerous notes and citations. To create an inline footnote, one simply places a caret at the point one wishes the superscript footnote indicator to appear, follow by the content of the note in brackets, thus:

##Using In-Line Footnotes with Pandoc

Here is my main text, rolling along and expressing its usual brilliance, followed by an inline footnote.^[Footnotes are cool.] As I continue to write, I can place additional footnotes using the same format.^[Cool like bow ties and fezzes]

When I run this through Pandoc, using the procedure outlined in Lesson Four, and open the resulting formatted text in a word processor (LibreOffice in this case), I get this result:

Output from Pandoc viewed in LibreOffice Writer.

Output from Pandoc viewed in LibreOffice Writer.

Note that Pandoc has automatically formatted and numbered the inline notes. It gets better. Let’s say I need to add a sentence to the above text that requires an additional note between the two initial ones, like this:

##Using In-line Footnotes with Pandoc

Here is my main text, rolling along and expressing its usual brilliance, followed by an inline footnote.^[Footnotes are cool.] I might even need to add a sentence that needs its own note later on.^[No, I'm not a *Doctor Who* fan. Why do you ask?] As I continue to write, I can place additional footnotes using the same format.^[Cool like bow ties and fezzes.]

Here’s the new output from Pandoc:

Pandoc output from edited original document.

Pandoc output from edited original document.

Notice that Pandoc has inserted the new note and automatically renumbered the other notes to accommodate my addition.

The value of creating notes this way for longer, more heavily-annotated documents should be apparent: instead of dealing with an “insert note” function at all, one simply creates all one’s footnotes right in line with the text, keeping the flow of thought contiguous and avoiding unecessary keyboard commands. No matter how much the plain-text document is edited, and no matter how many notes are added or deleted in that process, running the plain-text document through Pandoc again will always renumber footnotes automatically, meaning that the output from Pandoc will always be a “fresh” word processor document, with all the formatting and numbering of notes perfectly consistent. No more fiddling around with footnotes that seem to have a mind of their own.

There can be even more flexibility when inline notes are used with a citation manager, which we’ll tackle in a future lesson.

For now, your five-minute assignment is to create a sample document with both native markdown and Pandoc inline footnotes (if you don’t remember how to use Pandoc, refer back to Lesson Four, linked above). Or, better yet, try out the note functionality in some of your normal writing.

  1. Click on the arrow at the end of this note to return to the note’s position in the main text.  

Plain Text Writing Lesson Four: Pandoc Magic

Pandoc: The Magic Wand of Sustainable Document magic-wandConversion

Now that you’ve had some fun playing with a great text editor like Gedit, and have played around with Markdown syntax, it’s time to work a little magic on your plain-text writing.

Think of Pandoc like a magic wand: it’s a tool that takes your markdown text files and, with a few words, transmutes them into fully-formatted documents in the format of your choice (or the format required by a publisher). You can output to many different file types, including .docx (the native Word format), .odt (the native format for Openoffice and LibreOffice), .rtf (Rich Text Format, readable by many different applications), ,html (the format for web pages and blogs), and even (with a few software additions) PDF.

The one drawback of Pandoc, for the non-techy person, is that it’s a command line tool. In other words, there’s no snazzy graphical interface with pretty buttons to click. It works entirely with text commands inside a terminal window.

A terminal is simply an application on your computer that allows you to interact with it via text commands rather than graphical buttons. If you’re old enough to have worked with programs in MS-DOS, you’re already familiar with a command-line interface. There are two great things about command-line tools:

  • They’re incredibly fast. They tend to start instantly and work very quickly, just like your compact text editor.
  • They can be even more powerful and offer more options and functions than graphical tools. Think about it this way: a graphical tool is limited, in many ways, by the amount of space it takes up on your screen: there’s only room for so many buttons. A command-line tool can have as many available functions as its creator can imagine.

The drawback is the flip side of the advantages: you have to learn the text commands.

Luckily, you can do basic conversion with Pandoc with only a few commands, so it’s pretty darned easy.

Getting Pandoc

Let’s start by downloading and installing Pandoc.

  • Go to this page.
  • Scroll down until you see two large green buttons.
  • If you have a Windows computer, click the one that says “pandoc-1.13.1-windows.msi.”
  • If you have a mac, click the one that says “pandoc-1.13.1-osx.pkg.”

Go ahead and install the downloaded file (the one assumption I’m making is that you know how to install software on your OS of choice. If you need help with this, please leave a comment to that effect!).

Create a sample document

Let’s create a sample markdown document to work with. You can either type this in yourself or just copy it from here and paste it into Gedit (make sure each line is flush all the way to the left):

###Sample Markdown Document


**Here's a lovely bulleted list:**

- With this lovely line
- And this even lovelier line
- Iambic lines are very nice as well.

And just to show off an important function for academics, let's include a sentence that ends with an inline footnote.^[And here's the text of the note.]

Go ahead and paste this into a document in Gedit (be sure each line is flush to the left). When you save your file, make sure you save it with the “.md” extension (i.e. “”). That’s how Pandoc will know it’s a markdown document. For the sake of this lesson, let’s save this document as “”.

Save the file in a convenient folder on your hard drive (usually the “My Documents” or “Documents” folder).

Fire up A Terminal

This is where things get a little bit techy. But don’t worry–it’s not really all that techy, and ultimately pretty easy!

Start by opening a terminal window on your computer so you can issue text commands.

  • For MacOS: Open a Finder window and go to Applications and then Utilities; then double-click on Terminal. You can also click the spotlight icon in the upper right-hand corner of your screen and type “Terminal.”
  • For Windows 7: Click click the “Start” button, and navigate to “Accessories” and then “Command Prompt”
  • For Windows 8: Swipe up or click on the down arrow icon at the bottom of the screen. When you’re on the Apps screen, swipe or scroll right and located the Windows System section heading. Then click on Command Prompt.

Work Some Magic

Now that you’ve got a terminal open, we can type the commands we need to get Pandoc to work its magic.

Start by making sure you’ve got Pandoc installed. To do that, just type:

pandoc --version

The pandoc –version command and what its output should look like.

You should see a message telling you what version of Pandoc is installed along with a lot of other information.

Assuming that’s the case, let’s actually convert our document.

First, change to the directory in which you saved your test document. To do this, you use the text command “cd” (for “change directory,” naturally!). So, if you saved your test file in the “My Documents” directory in Windows, type:

cd My Documents

If you like, type “ls” (mac) or “dir” in Windows and you should see a list of files in the current directory. Make sure your “” file is there.

Then it’s just a matter of using some text commands to tell Pandoc which file you want to convert and what you want to convert it to. The general syntax works like this:

  • Start with the command that invokes the Pandoc program. Conveniently, this is just “pandoc”
  • Then tell Pandoc which file you want to convert. In this case, our file is called “”.
  • Then tell Pandoc what format you’re converting from. Do this with the flag “-f” followed by the file type (“markdown” in this case)
  • Next, we tell what kind of file we want our final output to be. Do this with the flag “-t” followed by the file type (in our case, “docx”)
  • Then we’ll tell Pandoc to create a standalone file, put its output in that file, and name the output file, like so :”-s -o PandocTest_Output.docx”

Converting our file with Pandoc in a Windows terminal.

Do do all this, just type all the preceding commands into one line in your terminal, like so:

pandoc -f markdown -t docx -s -o PandocTest_Output.docx

Then just press Enter. Your computer may think for a few seconds, but when a new command prompt appears, you’ll be done.


Our converted output in Word.

Finally, either use your file manager (that’s “explorer” in Windows) or Word to open the new file you just created. You should see your new, fully-formatted document, which should look something like the image on the left.

That’s your first conversion with Pandoc! We’ll cover more aspects of Pandoc in subsequent lessons, but, for now, just try creating and converting some documents according to your needs and play around.

In the meantime, if you’d like to look at some more complete documentation for Pandoc, you can do so here.

Happy writing! Feel free to leave questions or suggestions in the comments, especially if you run into problems with these instructions.


Plain-Text Writing Lesson Three: Markdown Elegance

Introducing Markdown, the Plain-Text Writer’s Power Tool

Everybody’s familiar with the usual way of formatting text in a traditional word processor, but have you stopped to think about how laborious the process normally is?

If you want to make a word italic, your hands come off the keyboard and one hand moves to the mouse. Using the mouse, you click and drag the cursor over a word (or double-click on the word) to highlight it, then move the mouse cursor up to the top of the screen to click on the “italicize” button along the toolbar. To create a footnote, your hands again leave the keyboard, you move your mouse cursor up to an “insert” pull-down menu, select “footnote,” which brings you down to the bottom of your page. You type the footnote, then scroll back up to where you were originally working in your document. Not a big deal once or twice, but such operations, when repeated over and over, actually consume a lot of time and break the flow of your thinking.

What if there were a way to perform all those operations as you go, simply by typing normal keyboard characters? Your hands would never leave the keyboard, and the mechanics of your software wouldn’t interrupt your train of thought.

This is where Markdown Syntax is a godsend.

Markdown syntax is simply a set of textual conventions, using standard keyboard characters, that indicate various kinds of formatting you want in your final output. Here are some of the basic conventions:

# Markdown Syntax:

## Hashtags indicate headings

### One for a level-one heading, two for level two, etc.

A string of three or more asterisks, like this:


Indicates a horizontal rule.

*An asterisk on either side of a word or phrase indicates italics*

**Two asterisks on either side of a word or phrase indicates boldface**

***Three asterisks indicate both boldface and italics***

You can use hyphens to indicate a bullet list:

- Like this

- And this

- And this

    - To create another level to your list,

    - simply indent the hyphen four spaces.

Indicate numbered lists as you’d expect, with numbers:

1. Like this

2. And this

3. And this

If you’d like to create a hyperlink, simply enclose the link text in square brackets, followed by the url in parenthesis, like this:

[This is the link text.](

You can indent a quotation by using a “greater than” symbol, like this

>Putting a "greater than sign at the front of a paragraph of text will indent the whole thing as a nice block quote.

There are a couple of ways of doing footnotes. We’ll explore two eventually, but

the first way is to enclose a caret and a "name" or number for the note inside square brackets, like this.[^1]

Then, at the bottom of the document, you create the note itself like this:

[^1]: Here's our actual footnote.

Here’s the magic. When you type a plain-text document using markdown syntax, it looks like this above. Once you’re done composing, however, you run your file through another piece of software that interprets your markdown and uses it to format a final document in the form of your choice, be it a word file (.docx), a PDF file (.pdf), a Libre/OpenOffice file (.odt) or a web page (.html).

For example, I can convert the mardown example above into html to incorporate it into this web page, and it looks like this:

Markdown Syntax:

Hashtags indicate headings

One for a level-one heading, two for level two, etc.

A string of three or more asterisks, like this:

Indicates a horizontal rule.

An asterisk on either side of a word or phrase indicates italics

Two asterisks on either side of a word or phrase indicates boldface

Three asterisks indicate both boldface and italics

You can use hyphens to indicate a bullet list:

  • Like this
  • And this
  • And this
    • To create another level to your list,
    • simply indent the hyphen four spaces.

Indicate numbered lists as you’d expect, with numbers:

  1. Like this
  2. And this
  3. And this

If you’d like to create a hyperlink, simply enclose the link text in square brackets, followed by the url in parenthesis, like this:

This is the link text.

You can indent a quotation by using a “greater than” symbol, like this:

Putting a “greater than sign at the front of a paragraph of text will indent the whole thing as a nice block quote.

There are a couple of ways of doing footnotes. We’ll explore two eventually, but the first way is to enclose a caret and a “name” or number for the note inside square brackets, like this.1

Then, at the bottom of the document, you create the note itself like this:

BTW, another way to indicate a footnote, which I think much more useful for academic writing, is called an “inline” footnote. Inline footnotes are indicated by a caret (^) where you want the note to appear followed by the note itself in brackets.^[Like this.]

Pretty sweet, huh? The beauty of this system is that all of your formatting happens in-line with your prose, which means that including it doesn’t interrupt your thinking. And, as I’ve mentioned in previous installments, when you edit and move things around, your formatting code moves in a natural, visible way (as opposed to all that messy underlying code in Word that seems so bent on destroying both your formatting and your sanity).

So, here’s your five-minute assignment for this lesson:

  • Fire up the new text editor you downloaded in the previous lesson.
  • Using the above formatting as a guide, do a little of your daily writing (some notes, a journal entry, some freewriting, an email, or whatever) using markdown syntax for formatting.
  • If you’d like a more comprehensive guide to the syntax or want to find out how to format something I didn’t mention above, there’s a great markdown “cheatsheet” here

That’s it for this lesson! Have fun experimenting with the syntax, and notice how much word-processor fussing it removes from your writing process. In the next lesson, I’ll show you how to convert your markdown to beautiful, fully-formatted Word, OpenOffice, or PDF documents.

  1. Here’s our actual footnote. 

Plain-Text Writing Lesson Two: The Editor

[Note: This is part two of a multi-part series on the joys of writing with plain-text tools. If you haven’t already, you might want to take a look at the first lesson, which covers why one might want to use plain-text tools in the first place. This lesson, and all the forthcoming lessons, are geared toward writers who aren’t techy and don’t have a great deal of time to devote to learning new gadgets and gizmos. They’re designed to take just a few minutes each to complete, with a view toward having a complete plain-text workflow in place by the time you’re through all the lessons]

Lesson Two: Let’s Get a Text Editor

If the first segment of this series convinced you–as I hope it did–that working with plain-text tools might be worth exploring, the next step is to get yourself a brand new text editor.

One of the great things about text editors, as I mentioned in the previous lesson, is that they’re extremely lightweight when compared to traditional office suites. This gives them two major advantages:

  • They’re lightning fast, even on older hardware. No whirring hard drives or laggy performance gets in the way of your thought process.
  • They get out of your way: The interfaces for most text editors are very minimal, giving you space to write and a few commands, many of which are accessible from the keyboard rather than mouse clicks. Working with the keyboard as much as possible also speeds you up: if you think about how many times your hand leaves the keyboard in order to grab the mouse when you’re working with a traditional word processor and add that up, it can work out to be a significant chunk.The less your hands leave the keyboard, the less there is to break the flow of your thoughts.

There are many flavors of text editor out there, and your ultimate choice of editor (or editors) will depend on how you decide you work best. I’m writing this in an editor called VIM, which is one of the more old-school and traditional options out there, and a long-standing mainstay for programmers. I like it primarily because of the gets-out-of-the-way factor: it presents you with only text in a terminal window, and works only with keyboard commands, keeping all my focus on what I’m doing.

Screenshot - 10292014 - 03:29:58 PM

The VIM editor running in a terminal. Nothing but the words.

The initial drawback of VIM, however, is that there’s a bit of a learning curve involved, since one needs to learn a lot of keyboard commands that make writing faster in the longer term, but not the shorter. So, for our purposes we’re going to start with something that’s geared more toward writers and more intuitive to use, an editor called Gedit. It’s available for all three major platforms (MacOS, Linux, and Windows), it’s free, and it’s intentionally designed to be as simple as possible.

So, your first lesson is to download, install, and spend a little time playing with Gedit. There are many different text editors out there, all geared toward different kinds of users and tasks, some more fancy than others. Gedit gives us a good starting point with its balance of simplicity and functionality.

Start by doing to the Gedit download page for your OS:

  • For Windows, go here, and click on the file with the .exe estension. Double-click on the file and follow the prompts.
  • For Mac, go here, and click on the file with the .dmg extension.
  • For Linux, if you’re using Ubuntu, Gedit is already installed, just access it from the menu or open a terminal and type “gedit.” For other distributions, just use your distribution’s package manager.

When you first open your installed version of Gedit, you’ll get a very simple interface that looks like this:


What you’ll see the first time you open Gedit. Clean lines and no fuss.

That’s it! There’s nothing else to do, at this point, but play around with writing in that nice, clean interface. You can save your documents just as you would with any word processor. When you first save a file, it’s good practice to give your filename a .txt extension. Note that you can have multiple documents open simultaneously and switch between them by clicking on the tabs at the top of the writing area.

You can also click “view” and then select “side panel” to open a side panel that will show your list of open files. Click the tab with what looks like a file cabinet at the bottom of that panel, and you’ll get a directory tree (very handy for working with multiple files at once).

If you want to make the interface a little easier on the eyes for longer writing sessions, you can change the color scheme and font it uses (note that this will have nothing to do with determining the font in your final output document; this is just about using the font that’s most attractive to your eyes while composing). Just click on the “edit” menu, select “preferences,” and then the tab for “fonts & colors.” You’ll get a list of several preset color schemes (I like the “oblivion” scheme, which gives you gray text on a black background). If you want to change the font, uncheck the checkbox that says “use the system fixed width font.” The otherwise grayed-out pull-down menu for selecting the font and size of your text will become active, and you can choose any font you like.

That’s all for now! Have fun playing with Gedit! Next time, we’ll look at the elegant MarkDown syntax, the most important “power tool” for plain-text writing.

If you run into any problems of have questions, feel free to contact me in the comment section.

Writing in Plain Text: A Tutorial for the Non-Techy Writer

Cuthbert-Gospels-John-1-1Inspired by a conversation with some of my advanced literature students, I offer, here, a short set of tutorials for writing productively (especially as an academic) using plain-text tools. Unlike most of the online resources on this subject, this series of tutorials is designed for the non-techy writer who doesn’t have a lot of time. The lessons are desgned to to be extremely simple, even if you’re a technophobe, and take only five to ten minutes to complete. By the end of the series, you’ll be up and running with a digital writing process that gets the technology out of your way and puts your creative process first.

Lesson One: Why Plain Text?

I’ll admit it, I’m a tech nerd. Or, at least, as much of a tech nerd as one is likely to find in an English department.

As I mentioned in my previous post, I think medievalists bring a kind of historical awareness to tech that allows us to see it more as a collection of useful functions–where novelty isn’t necessarily the only value–than a progressive march toward perfection. This approach allows us to ask not “what’s the newest thing?” but rather “what’s the best technology for the job?” in an awareness that the best tool for the job might potentially be a very old one.

One thing scholars in the humanities do all the time is write, and taking my “medievalist mind” to the available technologies for doing that has helped me light on some tools for supporting my writing that are in some ways older and less “high tech” than other options. For the same reason, however, they are also more stable, more sustainable, and (with a little practice) faster and easier to manage than traditional electronic writing with a word processing suite such as Microsoft Office.

The Elegance of Plain Text

To understand how working in plain text is helpful, think about the tools you normally use to write on a computer. If you’re like most, you default to a traditional “word processor” such as Microsoft Word. But consider this: have you ever had a problem with Word where some strange formatting seems to have sneaked into your document and you can’t get rid of it, no matter what you do or what settings you change? Have you ever had a Word document behave in infuriatingly odd ways for no apparent reason? Well, there is a reason, which is that Word documents are actually extremely complicated beasts. For example, a very simple sentence in Word, such as:

This is a simple sentence typed in the Word .docx file format

only appears to be very simple. Underneath what you can see in Word, there’s a huge amount of code that you don’t see. Here’s that same sentence with all the underlying word code revealed:


The image you’re seeing is only one out of nine pages of code Word generates to display that single sentence.

Hence the reason Word tends to misbehave, and misbehave more the more you work with a document. As you add edits, elements such as notes and images, copy text from other sources, rearrange blocks of text–in other words, most of the things an academic does with documents all the time–the more of that code is inserted, the more random and redundant strings of code interact and conflict with one another, and the more complex and unwieldy the document becomes. No wonder your document starts behaving as though it’s possessed by something unholy.

On the other hand, a plain-text file contains only the ascii characters that you type. A plain text file in which you type:

This is a simple sentence in plain text.

contains only the characters you typed, nothing else. If you make edits, rearrange things, paste in text from elsewhere, make lots of revisions over time, add sources, etc., you’re only rearranging and adding your text. Where a graphical Word processor might boast that “what you see is what you get,” a text editor can boast “what you see is what is there.” Nothing is hidden.

For this reason, plain text documents are much more stable and sustainable through the process of composition and revision than word processor documents. That doesn’t mean there’s something inherently wrong with word processors. What it does mean is that word processors are the right tools for the job when the job is formatting and processing complex documents, and not necessarily the right tools for the job when the job is writing.

A few other advantages of plain text:

  • It’s compatible with everything. You can edit plain text files on any device, with any simple text editor. You can work on your writing on any computer, your tablet, or even your phone without screwing up any formatting in the process.
  • It’s sustainable over time. As mentioned above, plain text doesn’t add tons of behind-the-scenes code the more you work with a document, so you can say goodbye to Word’s shenanigans. It’s also true that popular file formats change over time: if you wrote documents in something like, say, WordStar years ago, those documents take a lot of doing to access these days. Plain text documents have always been, and will aways be, universally accessible.
  • You can focus on your words. Word tends to be so complex, and presents you with such a dizzying arrange of options (most of which you don’t need unless you’re a massive insurance corporation) that the tool itself can distract from your writing. A simple text editor removes all that nonsense–it’s just you and your words.
  • You have more control over formatting. The basic idea behind a plain-text workflow is that you do your composing with a text editor in a sustainable, unversal format, and then, only when your text is ready to send somewhere–say, to a journal for publication–do you worry about formatting. We’ll cover how to make this work in later posts, but for now, imagine this: you’ve written an article as a text file. That file contains only universal formatting for everything–subheadings, footnotes, citations, etc. To format the file for different venues, you use another piece of software to convert that document into any format you like. One journal wants the document submitted as a Word document with citations in MLA style? You simply tell your conversion software that’s what you want, and, with a few keystrokes, ZAP! You’ve got a properly-formatted Word document ready to go. Another journal wants the same article submitted as a PDF with footnotes using the Chicago notes-bibliography style? A few more keystrokes and voila! Need to make some substantial edits after a peer review? Make those edits in the original text file and avoid all the formatting shenanigans your word processor always gives you.
  • It’s blazingly fast. Text editors are tiny pieces of software compared to word processors, so they start instantaneously, load documents almost instantly, and run like lightning even on old hardware. Nothing gets between you and your words.

In the end, the best thing about working with plain text is that it’s a technology that gets out of your way, allowing you to think and compose without distraction.

Convinced? If so, stay tuned for the next lesson, in which we will download and get started with some elegant text editing software.