About , I was changing jobs. I was leaving the walled garden of an IDE ↑ for a proprietary language that deployed to an AS/400 ↑ .
At my new job, I was writing web-facing applications using open source technology and deploying to Linux. I needed to find an editor to help me with the task.
I spent a bit of time exploring my options. During that exploration, I learned of Emacs from Carl Meyer.
At the time I had three young children, I had just changed jobs, changed programming languages, and couldn’t wrap my head around Emacs. I wanted my editor to behave like other GUI ↑ applications.
I didn’t take the time to walk through the Emacs tutorial, and left Emacs behind.
A few months into my new job, I switched languages and paradigms again. In , my company hopped in a van and drove to Chicago to learn about Django ↑ and Ruby on Rails ↑ . Within a week, our organization adopted Ruby on Rails.
At that time, I adopted Textmate ↑ as my editor. It had a beautiful user-interface and required little effort to learn.
At the time Textmate was closed source. I used it and loved it, but it began to lag. I found Sublime Text ↑ and switched. At the time, Sublime was positioning as a Textmate replacement.
Then, as I engaged more and more in open source projects, I started wanting an open source text editor. I learned about Atom in 2015. It was open source and acted enough like Sublime, that I switched.
Forward to . I had begun noticing more and more bugs and breaks in Atom. Not one to fear changing editors, I started looking.
I also gave VS Code ↑ a spin, and found it disconcerting. First, it felt constraining and off-putting. The configuration ecosystem felt clunky. The plugins felt like an App Store. Everything felt like VS Code was trying to obfuscate it’s underlying systems.
The proverbial last straw was the git ↑ prompt for commit messages. The prompt was a small input box; It didn’t encourage meaningful commit messages. Instead it encouraged terse commits. That feature alone told me that people using it will be encouraged to write bad commit messages. I didn’t want to be that guy with my text editor.
So, I spent a bit of time again testing vim ↑ and Emacs.
I again tried vim ↑ but it felt off.
I tried Emacs, and worked my way through the Tutorial. It was the strong commitment to the Tutorial and honestly the writing of that tutorial that nudged me to dive further in. I spent some time fiddling with Doom or Spacemacs, but in the end settled on bare metal Emacs.
This proved crucial. As someone that’s used text editors for 15+ years, I know the features I’ve used. What I chose to do in Emacs was to complete the tutorial and start coding.
If I found myself wanting a feature, I took note of it. Then, I went and found the package or packages that implemented the feature.
Now, 5 months or so in, I’m fully loving the experience. The community of Emacs developers seem to have a higher commitment to writing documentation.
Org Mode is the missing piece for my past text editors. Carstin Dominik took the time to build out functionality for organizing the non-coding tasks of software development, research, and writing.
Org Mode layers meaningful tools on top of plain text files; The syntax is close to Markdown, but different enough. The simplicity of structure makes the world of difference. With the plain text, I can run low-level Unix commands (e.g.
sed, etc.) but also have higher level programmatic access to the data.
Prior to magit, I almost always used command line tools for git ↑ . My previous workflow would be to use Terminal to state my git commits, and then my text editor to write commit messages.
Except for reading git logs, I now do most all git tasks with Magit. That includes an amazing interactive
git rebase environment.
I must mention this lowly command.
When Carl introduced me to Emacs, he showed me
fill-paragraph. That functionality stuck with me. It’s nothing fancy, but it shows that Emacs treats column-width as a first class citizen.
And why is column width important? First, re-read the note about commit message.
Conforming to that structure helps ensure that your
git log excursions are not unduly messy. It also helps if you’re going to interact with the command-line. In other words, automatic word-wrapping is nice, but its not universal, nor does it work in all contexts.
I have used this command to quickly wrap documentation so as to not have it flow off the screen.
It ain’t much of a command, but I’ve held a candle for it since I learned about Emacs.
I never knew I wanted Swiper until I stumbled onto it. I now use it all of the time; It’s even replaced my default Find behavior in Emacs.
What does it do? I type Control+S and start typing a word. In a mini-buffer at the bottom of the current buffer, I see the lines that include that word. It’s a bit like a find with context. Importantly, this doesn’t move my cursor in the main buffer.
So I end up quickly referencing something and get back to typing. Or, I can navigate through the mini-buffer and jump to that location in the main buffer. Quite slick.
The wgrep-ag package sort of blew my mind. It allows you to use ag ↑ with wgrep to edit search results
Follow along carefully:
In Emacs, I search a project using
ag. Emacs renders the search results in a mini-buffer. In this case, the mini-buffer is a small set of rows at the bottom of Emacs that show a subset of the results.
With the mini-buffer active (e.g. I’ve been typing results there), I invoke
ivy-occur. That function opens all of the search results in a read-only buffer.
With this new buffer, I invoke the function
wgrep-change-to-wgrep-mode. This toggles
ivy-occur buffer into an edit mode. I begin editing the search results as though it were it’s own file.
Then I save the edits, and
wgrep-ag writes all of those changes back to the found results.
Another way to think of it,
wgrep-ag loads a semi-structured buffer. Each row has three fields: file name, line number, and line text. I can use
wgrep-ag to write those changes back to the originating file.
Seriously, this functionality amazes me.
Textmate first introduced me to this powerful concept. Since then, this functionality has been a mandatory feature of my editors.
Two packages help deliver on this:
iedit - by default, if I type Control+
C-;), the iedit package highlights each occurence of the word. I can now type and iedit updates all occurrences.
- multiple-cursors - this package provides finer grain control, and allows me to set a cursor on ten contiguous lines and start typing.
I didn’t know what I was missing until I installed expand-region. Now with Control+
C-=) my cursor expands to the smallest logical region (e.g. highlighting a word), typing it again expands that region (e.g. highlighting the sentence), etc. And Control+Shift+
C-+) contracts the region.
org-mode, org roam incorporates note taking paradigms inspired by Zettelkasten.
I’ve used this to write up campaign notes for my New Vistas in the Thel Sector campaign. The bi-directional link and quick note capture tools make for a dream in information management.
In a way, it creates a Wiki that I can use Emacs to edit and navigate.
This year, Emacs drew me in. As I’ve entered my 3rd decade of software development, I’ve grown to appreciate tutorials, documentation, and owning my tools. Emacs delivers on all of that.
What I’ve found is I spend more and more time in Emacs, as it does more and more of what I want, all building from the basis of text files and directories.