name
# Text is Forever
by
Alex Cabrera
If you spend a non-trivial amount of time working with computers, you begin to develop systems for dealing with the information you need to process. Many keep all their files in their email or scattered across the desktop; others use intricate directory hierarchies and file naming patterns.
When your livelihood is tied to your capability to navigate within this system, the decisions you make take on an added heft. As the saying goes, "you can tell a lot about someone by their home directory"; and if that's not a saying, it probably should be.
Three Rules of Safe Computing
The problem, of course, is technology and needs can both change so quickly, that putting beliefs over pragmatism can be as paralyzing as having no system whatsoever (a rule that applies, more generally, to life as a whole). As such, my own system is designed around three basic and
RFC-2119 compliant
principles, derived in large part from my, sometimes irrational, survivalist paranoia:
1.
Nothing MUST be dependent on anything owned or controlled by anyone else.
2.
Everything of importance SHOULD be accessible forever.
3.
I SHOULD be able to be up and running within a day.
Adhering to these principles protects me from events outside of my control while allowing me to take advantage of superior, proprietary solutions where applicable. I can't use Windows, as everything I do would be one characteristically dumb decision away from being in jeopardy. However, I can use a Mac since its open *nix underpinnings means that once Apple decides to throw down the Gatekeeper gauntlet, I can still make a living with Linux running on a machine built from salvaged parts, or a
$25 computer
, in the inevitable Mad Max future I envision .
A Plain Text Strategy
These principles also mean that almost everything I do, at least anything important, is managed with plain text files. Formatted writing is handled by neither a proprietary format (e.g. Word Document), nor an obtuse open format that requires a specialized reader (e.g. RTF, XML); but instead by simple .txt files using Markdown syntax. Code is written in languages with open and free compilers that can be run in any *nix environment. The one gaping hole is email, for which I have not yet found suitable replacement; although, Sparrow's buyout means that a move to Mutt, or something like it, is in the cards.
Text files are not only universal, but they have always been, and will likely forever be, accessible. They are, for all intents and purposes, the atomic units of computing. Text files, above everything else, *must* be supported.
Maybe one day we'll do things with quants and holograms, but I'll hopefully be long dead. A world without text files is not a world I want to live in.
Tools for a Life of Text
The crucial importance of plain text in my workflow means that any computing system I design must have a well-thought strategy for handling these kinds of files. Over the years, through much experimentation and soul searching, I have settled on a suite of tools that meet my criteria.
vim
Vim has been around for two decades. It's the baby brother of a text editor that began life in 1976. That's about as stable as you can expect. It's a
modal editor
, which means you'll probably hate it the first dozen times you use it. It has arcane keyboard commands. You need to constantly maintain a
configuration file
(in plain-text of course) to get anything done. It's ugly, in a kind of beautiful way.
But it works; and it works everywhere. If you put in the time to learn how to use it, you never, ever have to learn another text editor. It does everything that you could reasonably want a text editor to do - it can be used for programing, long form writing, notes, ascii art. There are add-on bundles that change behaviors, support new languages, and can move with you wherever you go. If you keep your configuration file and bundles in
source control
, you're a quick `git clone` away from having a consistent environment on any machine, local or remote, you use.
I've opted to stay away from
MacVim
and other GUI-based implementations. I've found that you can get nearly the same kind of mouse support with some simple modifications to your
.vimrc
file and maintain a higher level of portability for your environment. If shit hits the fan, I can still use vim to get everything done.
But just because I
can
get everything done in vim, doesn't mean I want to. There are better tools for some specific applications of text files.
iA Writer
While vim is great for text manipulation, it's not so great for writing. The font size is small and it's easy to get distracted fiddling with configuration files. I've been a big fan of
distraction-free writing
applications since using an early version of
WriteRoom
; but almost every application built for that kind of writing still include one huge distraction - preferences.
Writer eschews any and all options. There is only one font,
Nitti Light
, because it's the perfect typeface for writing on a screen. There's only one font size, because that's all you need. There is one color combination. There are no formatting options outside of
Markdown
, which is all any civilized person ever really needs.
It's also available on all iOS devices; and it's the best option for writing on those platforms as well.
Almost everything I write that is meant for others to read starts out in Writer. If Apple ever does something that makes me leave the platform, losing Writer is going to hurt the most.
TextMate 2
I thought TextMate was dead. Along with Xanadu and Duke Nukem Forever, TM2 was the very definition of over-engineered vaporware. In fact, it was the apparent demise of TextMate that exposed my reliance on proprietary software and initiated my move to vim.
Then TextMate 2 was finally released; and it was unusable. Not just unusable from an
I-use-vim-and-everything-else-is-inferior
point of view, but just not very good. Then it wasn't updated for a long, long time. It was dead.
Then it was open sourced, and updates came - they still come - on a daily basis. TextMate 2 doesn't suck. It doesn't suck at all.
I can't go back to it for programming, but it's the perfect application for taking notes. Where Writer's lack of extensibility and configuration make it a bit cumbersome to use when you're not writing full sentences, TextMate is fantastic for jotting things down. It's my scratch pad.
Mou
Mou is a tiny app. It's maintained by a single developer,
Chen Luo
, who funds development entirely on donations.
Mou is also the single best Markdown editor ever built.
I use Mou for two things:
1.
Documentation that is then processed through
Markdoc
.
2.
Lengthy issues for GitHub
Mou is beautiful. Its live preview is flawless, can be customized using CSS, and ships with common themes; I know while I'm writing exactly how it's going to look on our build server or in GitHub. Each pane can scroll independently, allowing you to browse what you've already written without losing your place in the editor.
If you work with Markdown, you need to download Mou and then throw your wallet at Chen.
If text is so great, where's the support in Marquee?
Marquee
, the app I've been working on and what was used to publish this page, started life as Droptype – a Markdown-to-Dropbox publishing system. It was a hack that our team put together in a few days. There wasn't a lot to it: you put a text file in Dropbox, and it showed up as a formatted page on the web.
Still it solved a real issue: web publishing sucks. As I've
discussed
, it consists largely of filling out forms and mucking around with templates. It's terrible. Droptype was simple. It was distraction-free publishing.
It was also terribly limiting. As much as I love working with text, growing Droptype into something sustainable would mean having to convince a critical mass of people that they should follow the advice of this page.
That is well beyond my capabilities of persuasion.
Instead, we focused on building a web publishing solution that simulates the feel of working with plain text - simplicity, ease of editing, and portability - that could be accessible to anyone, not just people willing to run a 30 year old editor from the command line.
That being said, nobody would love it more if you could simply drop a Markdown file into Marquee and have it fill in the page than me. In fact, it would be great if I could backup everything I make in Marquee as a Markdown formatted file in Dropbox or GitHub. Getting there means building a few things we're not ready to talk about just yet; but given my proclivity for open, portable systems, we think we're building a solution that goes above and beyond that.
For now, text lovers can
sign up
, copy and paste, and accept my sincere apologies.
Discuss on
Reddit
and
Hacker News
.