I’m preparing to leave behind Atom. It’s been a good run, but it’s not meeting my needs.
As I was practicing using Emacs, I found myself looking into configurations and plugins. Before I got too far, I wanted to write-down why I’m going through this exercise.
First, my guiding principles as I explore a new text editor.
- It must be FOSS 📖 .
- It must have a sizeable community of adopters.
- It should not be based on Electron.
- It must be extensible, preferrably via a scripting language.
- It must have good documentation.
- It must have a keyboard first focus. Yes, I will use a mouse, but I want to favor my keyboard.
- It must run in Linux or MacOS.
- I must be able to store its configuration in source control.
- I must be able to share the configuration between MacOS and Linux.
And I would like if the tool and ecosystem “jived” with my philosophy and mental models.
When working on a project or group of files, I often have multiple tabs open in my text editor. At the top of my editor, I can see what tabs are open. I can use number keys (plus a modifier) to open that tab. As a bonus, I can click on the tab to open it.
Oddly, I don’t often use split pane, but that feature is nice when possible.
I often work with data from disparate sources. And sometimes those come with little surprises. I need to see the invisible control characters that may be impacting that file.
Fuzzy File Opening
Since my Textmate days of yore, I’ve relied on CMD+t to open a file finder; The file finder used a fuzzy match for file names. I don’t want to type the filename exactly, instead I want to start typing. The candidate results should have those typed letters, but they need not be contiguous. Further typing narrows the candidate pool.
For example, if I have three files: README.md, red-rom.txt, and ruby.rb, when I type “R”, all three files would match. Then “re” would match the first two, and finally “rex” would match only red-rom.txt
Already, as I’m writing this, I have Ctrl + d mapped to a duplicate line function. In other systems Ctrl + d will delete a character. That is an engrained keystroke incantation that I need to think through what I want.
I also make heavy use of Ctrl + w to highlight a word, then delete it. Right now, my Ctrl + w in emacs invokes “kill-region”, which is very aggressive compared to my current Atom keymap.
I should have the ability to re-map keys, see what keys are already mapped, and even unbind mapped keys.
In the last three editors I’ve used (Atom, Sublime, and Textmate) all of them provided a file browser area. That area showed me all of the files in the current editor’s context. Typically this was the directory structure from which I opened the editor.
The file browser helps provide reminders and orientation to the structure of the code-base.
Git Commit Message
I can live without integrated git. However, I want to use my text editor for
writing commit messages. When I run
git commit from the command line, it
should launch the text editor in a timely manner (350ms or less).
I aim to write good commit messages. One of those rules is that the first line of a commit message should be no more than 50 characters. And the body wrap at 70 characters. My text editor should help me structure good commit messages.
Any integrations of the text editor and git should follow the same above listed principles.
Launch from Terminal
I should be able to launch my text editor from the terminal. Either at the current directory or at a location specified as a parameter.
Regular Expression Search/Replace
I must be able to search via regular expression and change text via regular expressions. I use this quite often through Atom.
Other Nice to Haves
I love my current Atom Markdown Preview package. That would be nice to duplicate. Likewise for PlantUML preview.
I often use a multi-cursor edit function. I mark different spots in a document (usually via find) and start typing my change. Or, I’ll mark 10 consecutive lines at the same column and start editing there. If I invoke a cursor moving command (e.g., go to end of word), then the mark moves to all end of words.
Ideally, when I’ve gained some proficiency, I want people watching me using my text editor to be just a little bit lost. In other words, I need my text editor to keep up with my pace of thought.
These are my guiding principles and some of the features I require. I’m certain there are others that I’ve internalized, and not yet explicitly acknowledged.
What sold me on giving Emacs a go was its strong commitment to documentation. I’ve tried Vim several times and it never quite sat well.
The shipped tutorial is amazing, using accessible language and seeking to gently guide you through the ecosystem.
C-h k lets me look up what that key combination does. The
C-h f helps me go hunting for commands that I may not remember.
I’m currently exploring Emacs, and went through the fantastic tutorial that ships with Emacs.
I made it through 60% of the tutorial, and then started poking around with plugins and configurations. I went so far as to install Doom emacs. I found myself poking around in what I could do, instead of building from a small start.
I removed Doom and went back to my simpler
~/.emacs file. I’m sure as I
explore, I’ll look to other packages or configuration frameworks.
In otherwords, this is my reminder to build up from a smaller foundation, and own each brick that I place.