Principles of My Text Editor

Once Again Exploring a Different Solution

By on ::        

update

I’ve been using Emacs 📖 since , and wrote about the Emacs packages I am currently using. Over the weeks and months, I’ve configured Emacs to suit my needs. I’ve reworked the colors of my site to match an Emacs theme.

At this point, I’m happy, enjoying my text editor, and can’t see switching.

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.

Principles

  • 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.

Let’s talk a bit about Electron. First, in my observation, Electron based applications devour resources. Second, by their nature, they must keep pace with browser evolution (HTML 📖 , CSS 📖 , and Javascript). Maybe it’s me, but Javascript-based systems require a ridiculous amount of ongoing maintenance and weeding. Have a different opinion? Let me know.

And I would like if the tool and ecosystem “jived” with my philosophy and mental models.

Functionality

Tabs

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.

Invisible Characters

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

Keymapping

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.

File Browser

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. The Seven Rules of a reat Git Commit Message 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.

For a week, I tinkered with VS Code. And aside from its somewhat off UI, I could not tolerate VS Code’s commit message input box. The box encouraged very short commits, which I find violates the aforementioned Seven Rules.

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. Though over the last month, I’ve noticed that it’s been somewhat inconsistent. I’ve had cases where the regular expression updated 80% correctly, but left token markers (e.g., “$1”) in other updates. For example, if I had a regexp of /(up|down)/ and replaced it with go-$1, in 80% of the cases, I’d see ‘go-up’ or ‘go-down’ but in other cases I’d see ‘go-$1’. That flakey behavior is one of the drivers for leaving 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.

Conclusion

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. I can use Vim well enough to update text in a file, but have found it to work exceptionally well for my brain.

The shipped tutorial is amazing, using accessible language and seeking to gently guide you through the ecosystem. I believe one more trip throug the tutorial and the basics would gel.

The invocation 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.

Postscript

I’m currently exploring Emacs, and went through the fantastic tutorial that ships with Emacs. When you install Emacs, type C-h t to start the tutorial. (Type the “control” and “h” key at the same time, then type the “t” key.)

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.