On finding a new text editor

I’ve spent an unreasonable amount of time this summer evaluating a few different text editors after Atom, the application where I did almost all my writing and notetaking between 2016 and 2022, got the axe from its corporate developers. I’m writing this post to capture my reflections from this largely procastination-fueled quest for the right editor before those thoughts vanish on the wind. Maybe it can also serve as a kind of Wirecutter-ish tour through some choices for people in a similar boat – that is, humanities researchers who use or might want to use a plain text workflow instead of a word processor. The choice I ultimately (and unexpectedly) arrived at was to use gedit, which was simply the built-in text editor on my operating system (Ubuntu Linux – gedit is also available for Mac OS, though I haven’t tried it there yet). People on other operating systems, especially those who already use Atom (edit December 2022: I just learned there’s a fork for ongoing maintenance of what was Atom as Pulsar; I haven’t tried it out but it might be where you want to look first if you were an Atom enthusiast), might want to go with Codium or Sublime Text, or something like StackEdit if you don’t mind working in a web browser. But gedit’s simplicity and built-in-ness were just as important to me as its features, so this post is also a defense of starting out with whatever text editor you have on hand.

Just before starting a PhD program in 2018, I happened upon Scott Selisker’s “Plain Text Workflow for Academic Writing with Atom.” It was a lucky and timely find: I had used Scrivener (the writing environment that provided some inspiration for Selisker’s workflow) to draft my MS thesis a few years prior and had used Atom nearly every weekday since then during a job as a digital humanities developer. Working on websites and code documentation for that job meant I was already familiar with markdown, the markup language that Selisker uses (this post and most content on my website are also written in markdown). Heading back into school, I was eager to set up a workflow that combined what I liked about these tools and that could help me stay organized amid an onslaught of reading. I also borrowed part of my notetaking approach from the design of a specialized markdown notes editor called The Archive. This category of markdown-based tools for researchers has kept blooming a bit in the time since, e.g. with the mind-mapping application Obsidian or Zettlr. Other tools for academic writing popped up as packages (i.e. plugins, extensions) for Atom, including nice integrations with the citation manager Zotero. Since I knew some Javascript, I could make Atom packages of my own to do simple time-saving things like clean up messy text blobs on their way over from PDFs I was reading. Atom’s package repository showed that a bunch of other people installed that one, which made it feel like I was in a loose but sizeable community of people using the application for research and writing.

The old setup in Atom

The big appeal of a plain text workflow for me is that it’s just files in folders. It reduces some minor but massively-recurring frictions (e.g. clicking all the way through to a new blank document in Word, or wondering which larger document a note belongs in) that stand between noticing an idea and storing it on my hard drive. The resulting heap¹ of text files are then readily searchable from the regular file browser on any operating system, and they’re also very transportable – I sync my Notes and Dissertation directories to Dropbox, where they use up a tiny fraction of the free storage space. They move between computers and software applications without any need for format conversion. When my old MacBook called it quits heading into my fourth PhD year, I just set Dropbox up on the refurbished Ubuntu laptop that replaced it; this automatically retrieved all my reading notes as well as the Dissertation > Snippets directory that had been slowly but steadily growing over the first three years whenever I spotted or thought of something that seemed like it belonged. Around that time I started sorting these short text files into “chapter” buckets as I got a better sense of the dissertation’s structure. Then, when I really got underway with writing the thing itself, my work consisted of filling in the gaps between these fragments – some of which I had totally forgotten about in the time since jotting them down.

Then, in summer 2022, Atom got its curtain call. Its maintainer, GitHub, had been acquired by Microsoft in 2018. In announcing that it would sunset Atom, GitHub touted “new cloud-based tools” including Microsoft’s Visual Studio Code as superior alternatives. The decision seemed pretty transparently driven by Microsoft’s desire to shepherd users into a single program, VS Code. It also treated Atom’s user base as entirely made up of coders, which is incorrect. VS Code seemed like a very unappealing alternative for these reasons, but I decided to give it a try after someone on Mastodon pointed me to the open-source version that bypasses Microsoft’s telemetry. This version, VSCodium, did impress me as an alternative to Atom. Most features I’d enjoyed were available, and the coding-specific features didn’t impinge on the writing experience to the extent the application’s name suggests they would. A good number of packages, including Zotero integration, were available and even easier to install than in Atom. Despite these pleasant surprises, I couldn’t shake two sources of unease. First, while I suspect it would be pretty easy to port my own Atom packages over to Codium, I didn’t like the idea of uploading my work to the Microsoft Marketplace that now served as the repository for extensions. Second, I fear that Microsoft plans to next pull the plug on the desktop versions of VS Code in favor of shepherding users into an in-browser application – all the emphasis on “cloud-based tools” in the death-of-Atom announcement seemed like cause for concern. I’m very uninterested in relying on internet access to work on my writing projects and don’t want to have to switch editors again anytime soon. So I decided to look in a dorkier direction.

For a while, and especially since switching from Mac OS to Linux, I’d had a nagging interest in switching from Atom to a tool with more free/open-source software cred. Atom wasn’t perfect: its underpinning framework, Electron, essentially means that a whole web browser is running in the background, making it more resource-intensive than a text editor should be. There was also the association with GitHub and now Microsoft that became more salient by contrast when most of the software I now used was maintained by volunteer communities. I wasn’t interested in moving into the command line, but I was vaguely aware that Emacs, an editor that has been around for an epoch and is still going strong, was able to split the difference between the bare bones GUI-less approach and something more elaborate. I also saw people post about fantastical productivity-enhancements to academic writing and just to daily computer tasks through customizing their Emacs setups (there seem to multiple Emacs equivalents to Selisker’s guide; I didn’t dive quite far enough in to be able to recommend a particular one). Paul Ford’s delightful reflection for Wired on software configuration upped the intrigue, though in hindsight it probably should have been a warning. Wanting to get up to speed quickly and replace the basic workflow I had used in Atom, I decided to try a tool called Doom that morphs Emacs into a full-featured modern editor by curating a set of packages for it.

Reproducing my setup in Doom Emacs

While I ultimately found Emacs and Doom frustrating, setting it up was a good provocation to reflect on which features I really want in a text editor and why. To Doom’s credit, they were just about all available by activating (un-commenting) module lines in its configuration file. They include:

• A simple file browser sidebar: I tend to jump back and forth between two or three snippet/section files while I’m writing, so my directory contents act as kind of a mini-outline in addition to a navigator. Treemacs, a package that Doom includes as one of its modules, provides this.
• Split-window arrangements of multiple files: having a draft and its corresponding outline open side-by-side, perhaps along with a relevant note in a third partition, is really handy and helps me steer my writing without breaking the flow. Treemacs has a nice set of keystroke commands that will open a file in the spot you want it.
• Easily togglable full-screen mode: writing without any other OS elements or notifications visible really does reduce distraction for me. The Zen package, also included with Doom, is designed to do this.
• A way to quickly pull citation keys from my Zotero library into the text file (as explained in Selisker’s post, the workflow uses shorthand references generated by a Zotero plugin called Better BibTex and then expands these into full citations when you compile your document from markdown to Word/PDF/etc.). The Doom-included tool to do this is Citar, which was a little more complex than what I was used to but which worked well.
• Text cleanup for quotes pulled from a PDF: I mentioned above that I made my first Atom package to do this; it turns out that once you get used to not needing to manually repair line breaks / hyphenations or change typographer marks (“) to standard subquotes (') all the time, it becomes very annoying to do it again. I couldn’t find an Emacs package that does this. I assume that it would take two, maybe three lines of elisp code in the Emacs configuration file do add this feature. But for me, unfamiliar with lisp and already a little weary at the Emacs learning curve, it didn’t feel like an easy addition.

My problem with Emacs, ultimately, was that I liked my exisiting operating system and didn’t want to run what turned out to be a whole other operating system inside of it just to write. All the tools I use outside the text editor, including Zotero, the file browser, PDF readers, and even email, could be subsumed by Emacs with the right configuration. I got far enough in to understand why this is very appealing to the right kind of user but also to be somewhat repulsed by it myself. That feeling was largely because, despite Doom saving me the work of tracking down the right modules, these add-on features didn’t seem to interact particuarly well with one another. Zen-mode, for instance, only did what I wanted it to do if I remembered to toggle Treemacs on before toggling fullscreen. I’m still confused about how the Projectile package communicates with the Workspaces package, which can retrieve your document windows from a previous session but evidently can’t re-open Treemacs. The highly modular architecture was great in theory but proved confounding in practice, with the added frictions that the overall interface lacked visual coherence and that the Doom documentation uses a playful tone that I found irritating when trying to troubleshoot. I started to feel the benefit of not relying on a mouse/trackpad that would come with learning Emacs’s powerful key-command interface, but I also questioned whether it was worth the confusion of practicing different shortcuts for basic operations like undo, copy, and paste that I use in other programs all the time. The thought of spending enough time to learn the Emacs way of doing things so that I could use it properly started to become exhausting. It occurred to me that maybe I could go in the other direction – instead of something more complex and robust than Atom, maybe I could use something simpler and rely on other tools for more features, instead of continually extending the central tool.

My current gedit view (with the additional gedit-plugins Linux package)

This was my thinking when I took a closer look at gedit, the default text editor for the GNOME desktop environment that had come bundled when I installed Ubuntu.² gedit does a good job of presenting a bare bones interface when you first open a file, somewhat analogous to TextEdit in Mac OS but without that program’s rich text default. It turns out, though, to have a streamlined but impressive set of plugin features available a few clicks away. One of these provided exactly what I was looking for: the built-in “external tools” plugin lets you assign a keyboard shortcut to a small script in Bash, the language the command line terminals on Linux and Mac OS use by default. In other words, the editor helps you launch a little micro-program you’ve designed and that you could just as easily launch outside the program (but it makes the document/selection contents available as input for that micro-program and lets you pop its output in at the current cursor position). This meant I could pretty quickly reproduce my PDF-quote-cleaning add-on, which used 187 lines of Javascript as an Atom package, as a single-line Bash script (albeit with a very unattractive cluster of regular expressions):

xclip -o -selection clipboard | tr '[\n\r]' ' ' | sed -E -e "s/- //g" -e "s/[ \t]*$//" -e "s/[\"\“\”]|[\’\‘]+/\'/g"

(This command pulls the current clipboard contents, removes any line breaks, removes the hyphen-space sequence left over in any line-wrapped words, trims any spaces/tabs from the start and end, then replaces any typographer quote marks and/or double quotes with standard single-quote marks for subquotes.)

I got even more excited when, after searching for a gedit-Zotero interface and coming up empty, I eventually realized that this too could be built in a single line. Thanks to an elegant design choice in Better BibTex, the Zotero plugin that I had already been using, it turned out that the following suffices as an external tool to pull up a Zotero entry picker and pop the selected citation key in at the gedit cursor:

curl -s http://127.0.0.1:23119/better-bibtex/cayw?format=pandoc\&brackets=true

(This command uses a local http request to ask Better Bibtex to launch the citation picker popup, which waits for the user to pick an entry and then returns its key, formatted so pandoc will find it and turn it into a citation at compile time.)

The external tool for Zotero integration and the popup it launches

I very much hope that gedit won’t fall out of maintenance any time soon, but even if it does, the work I’ve done so far to customize it for my needs won’t have been a tremendous lost investment; it’s been both highly straightforward and highly reusable. I do feel a little sad to miss out on the much livelier user community around Emacs, which includes people making and using some very impressive workflows around academic writing. But at the same time, I’ve always wanted my workflow to be more legible to the smaller community of peers who inspire my actual research and writing. Using a text editor that has been a built-in standard for years, that fits in well with its surrounding operating system, and that is intended to interact well with outside tools rather than to replace and subsume them, feels like a step in that direction.