My Terminal-First Blogging Workflow

2021-02-25

You don’t need fancy WYSIWYG editors and complicated plugins to write your blog, you just need a text file and some basic Unix tools.

Storing Ideas

I store ideas, that is one sentence concepts, in a Markdown list. Just the briefest way to sum up the topic I’m considering writing about. I’ve seen others use tools like Notion, Roam, and other “second-brain”-type systems for storing ideas in these complex interconnected databases and tables, however these all seem somewhat excessive for the use-case. After all at this stage it is only an idea, fleshing the topic out comes later.

I’ve generally found that storing every idea in a single list is the best way for me personally to skim for new things to write about. It reduces any friction that may occur by grouping items into separate folders with the added benefit that, by placing random topics alongside each other, it may spark new ideas or connections.

Structuring Drafts

Keeping things minimal and concise, posts that have graduated from the idea phase are moved into one of four folders:

started
Where the first draft lives, here snippets of sentences and sources etc are stored. A sort of pseudo-scratchpad while I collate things together.

onhold
Posts that have been written but just aren’t quite there yet - a place for posts that are stuck at 90% complete. A post will generally end up here if I’ve been working on it for a few days/weeks and I’m struggling to tie things together. For the time being, I’ll store them here in the hopes of returning at a later date with a fresh mind.

shelved
This folder stores posts that were completely written and ready to publish but didn’t hit the mark, either in quality, clarity, or the topic simply didn’t merit publishing. I don’t outright delete the post in case some aspect could be transplanted to another future post. Think of this folder like a lower priority onhold.

written
The final, reviewed, ready-to-go post is stored here. This should be a 1-to-1 copy of the final published version on the site for posterity.

Actually Writing

When it comes to actually writing a post, like almost everything I do that’s text-related, it happens in Vim. As before, I start putting together paragraphs and sections in Markdown, iterating over the draft until it’s ready.

Although I do try to keep my Vim configuration somewhat minimal, I do make concessions for a few plugins that really make the writing process much more pleasant (Both are actually by the same author).

The plugins in question are:

Goyo
Goyo is effectively a focus-mode for Vim. It works by hiding all the visual elements of Vim like the status bar, line numbers, and other visual clutter, leaving only your text. In addition, the file is reformatted to a specified width and placed in the centre of the screen for improved readability.

Limelight
Limelight makes an excellent add-on to Goyo by reducing distraction even further by only highlighting the section you’re currently working on. A useful feature on larger, more dense articles.

Editing

Editing was an aspect I’d previously found harder to deal with effectively in the Terminal. Before, I’d been using Grammarous in Vim however it seemed to miss mistakes too frequently to continue using confidently. After some digging I stumbled upon aspell, a terminal-based spell checker, which had a far higher hit rate in detecting incorrect words and general errors. I love the easy 1,2 or 3 approach to correcting text that means I can fix issues quickly and accurately.

On Mobile

If I need to jot down ideas or review a post from my phone, I use Termux. The fact that Termux allows for most Linux applications (like Vim, Git etc.) to be installed is fantastic as it offers me a complete desktop-like experience without any sort of trimming down for mobile.

In fact, most of this article was written from my phone!

Publishing

Once a post is complete, checked over for formatting and spelling etc, I’ll run it through my set of scripts which handle converting from Markdown to HTML and give it a final read over as it would be presented on the site. If all’s good, I’ll run make publish, a small makefile script which handles the final extra features like SEO tags, additional styling etc. and the post will be live.

And there you have it, a minimal Terminal-first writing workflow. Will such a workflow scale well to dealing with 100 posts? 1000? Maybe not in its current form but the independent, offline nature of each of my workflow’s components and tools certainly make room for expansion and adjustment much easier.