On I presented on Org-Mode and Emacs to the developers at Scientist.com. Below is the introduction to that presentation:
There’s something about the 1970s; two of my favorite technologies come from that decade: Emacs and Structured Query Language (SQL 📖). And also my friend Dungeons and Dragons. The four of us have seen many technology paradigms come and overstay their welcome, ultimately creating barriers to ownership, adoption, and maintainability.
I want to delve into one of those technologies; my beloved Emacs. In I moved from Atom text editor (Atom 📖) to Emacs; and I have found what I hope to be my final text editor.
In preparing for this Show and Tell, I chose to focus not on projects nor the production code I write, but instead on the tools I use.
Let’s invoke Stephen Covey: “Habit 7: Sharpen the Saw is the principle of renewal. It is the habit that makes all the others possible.”
Emacs is my saw and quickly became the linchpin of my workflow.
During my work day I jump from project to project; concept to concept. I have built up a workflow and tools to help me navigate this text-based life.
During that presentation I talked and walked through my use of Org-Mode. I also mentioned both my text editor history, referencing writing up Principles of My Text Editor .
The history I mentioned regarding text editors was:
- JEdit
- My first editor for web development.
- Textmate
- TextMate roared onto the scene alongside Rails; it made sense to adopt.
- Sublime Text
- Sublime Text had solved the slowness of Textmate’s search.
- Atom
- I wanted an open-source editor that I could extend.
- Vim
- I saw the writing on the wall for Atom and choose to explore this along side Visual Studio Code (VS Code 📖) and Emacs.
- VS Code
- The Vim paradigm didn’t quite work for me.
- Emacs
- I abhorred the Git commit message interface of VS Code, and recalled a gentle nudge almost 15 years prior.
One of the attendees wondered the following: “I’m a long-time user of TextMate and perhaps I should be looking elsewhere. However, with any move to a new tool there’s a time investment required to get situated. Can you talk about how you can make that decision to jump?” This was paraphrased from memory. My response was along the lines of “write up the must haves of your workflow; the functional needs. Then if and when you practice moving to a new editor, practice those must haves.”
I went on to say “When I switched to Emacs, I jumped into Spacemacs. But after a bit, I decided to start from the beginning. I removed Spacemacs and worked my way through the tutorial. Then I just started writing. And when I wanted to do something I previously did, I’d stop and seek out a package, install it, and experiment with it.”
That conversation sparked my desire to revisit the principles of my text editor. And I’ve settled on the following:
My text editor must facilitate my engagement with the ever evolving digital aspect of my life.
My initial thoughts as I pondered this revistation was that it should help me organize my digital life. But organize implies a consumptive relationship; things come at me and I need to file them into buckets.
And the “ever evolving digital aspect of my life” phrase reminds me to look at what I’ve done, am doing, and might do.
The connecting phrase “my engagement” reminds me that I should actively tend my digital garden. Give attention to the tools I’m using; prune packages I’m no longer using, think about a different way, practice and explore the problem space that is my editor experience (not the problem space I solve with my editor).
The Ever Evolving Digital Aspect of My Life
Let’s look at my digital life; my resume (and this blog) provide many clues.
Prior to my work was in proprietary ecosystems; the company prescribed my text tools. I wrote code during the day but at night my life was family time and analogue games.
From forward, I began writing code using open-source 📖 languages and frameworks. This opened the door to picking my tools. And up until I started blogging in , most of my digital writing was email and code.
The explosive moment of evolution was choosing to migrate from a hosted Wordpress to Jekyll in . You can read about that migration in Welcome to My New Take on Rules. I have since moved from Jekyll to Hugo. I moved from writing blog posts in a textarea on a web-page to writing posts in the tool I used for writing software; which was Atom.
Looking at my Posts by Year page, it’s easy to see that after this migration I was writing more than I had in most years prior. And if you dig further my switch to Emacs in was another accelerant in my writing.
For my experience, investing time in my code editor is also investing time in my note taking and general writing tool.
Paying Attention to the Journey
A constant throughout this evolution has been introspection; paying attention not just to what I was doing but how I was doing it.
Examples of that include:
- Moving from word to word; I’ve long used OPT plus arrow keys to navigate.
- Jumping from test file to “production” file; TextMate introduced that for Rails.
- Opening new files by text prompt; Again TextMate’s CMD + t started me down this path.
In other words, these text editing tools have helped me move quickly between and within files.
And these editors of ours also have the concept of snippets; a sub-system that you can select a snippet, perhaps fill out some information via a prompt and then write the snippet’s boilerplate with the prompts filled in.
In my wanderings, I’ve seen so very many tools that allow you to import TextMate’s snippets to use in their system; think on that for a moment.
Textmate introduced a syntax that other editors not only drew inspiration from but choose to repeat it’s syntax. The formalization of the computational description of snippets, paired with their portability (e.g. they were simply text files on your machine) helped create the conditions for a plugin ecosystem.
You can see that through line in Org-Mode. First starting in Emacs and Org-Mode’s syntax as a spec with an org-parser and folks writing Org-Mode files outside of Emacs.
Intuitions Once Heeded Now Named
Earlier I mentioned my issues with VS Code and Rubymine; and sometimes to know what you want you must identify what you don’t want.
Interface of VS Code
In my brief exploration of VS Code, two things initially bothered me along with a third:
- Git commit message interface
- Marketplace for features
- Embrace, Extend, Extinguish
Git Commit Message Interface
The first time I went to write a Git commit message in VS Code, I was greeted with what looked like an text field; a 30 character input box. I canceled out and launched VIM to write my verbose commit message.
That experience sat with me for a bit and I got to thinking; source control and commit messages are one of our most useful tools for writing about the why of a change. They provide historical context for a moment in time. That context moves with the code-base.
And VS Code was encouraging terse messages. I started extrapolating what could that mean for the ecosystem? The past is irrelevant only the now matters. The code is more important that any additional clarification someone could provide.
That apparent philosophical decision was the deciding point to eschew VS Code. I’m certain there are plugins that could remediate the situation. But here we had a flag ship open source product that was encouraging what I consider bad behavior with a critical open source platform (e.g. Github) that they owned. I could conject and posit; but I’ll leave it here.
Marketplace for Features
I understand that I should invest in my tools. And that can mean time and money. Something about the User Interface (UI 📖) of VS Code felt as though I was one moment away from “We’ve got an app for that.” It felt as though my editor was steering ever closer to a Philip K Dick reality. I’m thinking about Do Androids Dream of Electric Sheep, and dropping nickles into the door and toaster. Which leads to the next concern.
Embrace, Extend, Extinguish
Microsoft had (and has?) a strategy of embracing open source, extending it with proprietary functionality, then asphyxiating the open source viability due to the reliance on proprietary functionality.
This may not be in play for VS Code, but the days of independent computing are under attack. The personal computer has given rise to a tremendous explosion of workers having the means of production.
Technology corporations are maneuvering towards all things hosted; this is a means of eroding that “means of production.” Host your text editor in the cloud; run you application in the cloud. To make your product with those tools you become beholden to the terms, conditions, fees, and fiat of the provider.
VS Code is a foot soldier in that maneuvering; Co-Pilot is also enlisted in this battle. As are the plethora of services you can leverage and consume to cede your means of production.
Rubymine Not Setting Right for Me
I forget when I was exploring Rubymine, but I recall thinking “I don’t want a tool for just one programming language.” Getting better at using Rubymine would likely only help me get better at Ruby; not HTML, nor Javascript, nor CSS, nor Shell scripts. Or writing SQL. Or any other programming language that I need to use.
But I now extend that framing as well as re-orient my focus. The purpose of my text editor is to facilitate the conveyance of thought; to my current and future self (and hopefully the Me myself Whitman so named); to the computer that I’m telling what to do, and to others who stumble upon digital representations of my thoughts.
Part of my job as a software developer is writing code; much more of it is writing up analysis, design documents, writing task breakdowns, and the myriad of other forms of documentation.
What if we could flip our expectations just a bit. What if the only thing that mattered was the documentation? The why mixed with the how. And the byproduct of all of that would be the code; the instructions we tell the computer.
Conclusion
I don’t envision moving away from Emacs; I’ve been able to extend the tool to meet my developing needs and explore my curiosities. Emacs fundamentally is a REPL tool. I can adjust my editor on the fly: adding, removing, and adjusting functionality. It has amazing introspective capabilities. And a vibrant community of contributors and enthusiasts.