As a software engineer, a text editor is probably the most important tool in my toolset. Therefore, I want an editor that’s easy to work with and helps me get my work done.

I use VS Code day to day. I like that it has a plug-in for just about everything, and solid online support when things go bang. While I feel comfortable with it, I like to explore new tools.

As I dove into the ongoing editor wars, I found myself intrigued by Emacs and decided to see what all the fuss was about.

For all you Vim devotees, don’t panic - I’ll give it a go one day.

Background#

Emacs (originally an acronym for Editor MACroS) is a text editor built on top of a Lisp dialect called Emacs Lisp. Emacs Lisp is a programming language in its own right, and being part of the Lisp family of languages makes Emacs incredibly flexible.

Emacs makes heavy use of keyboard shortcuts and keybindings, making it a (mostly) text-based text editor, so typical use doesn’t require the mouse, though modern Emacs can be used in a “point-and-click” fashion.

For my exploration, I didn’t want to stick with vanilla Emacs - it’s kind of boring. So I did some research and stumbled upon Doom Emacs.

Impending Doom#

Doom Emacs is a configuration framework built on top of Emacs that aims to make the experience faster, more modern, and easier to use.

I think the Doom Emacs GitHub page puts it quite well:

Doom is a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better).

From my point of view it made Emacs feel a little like VS Code in that it adds a package manager, a few config files, and some lovely themes.

Doom also has useful command-line tools, such as doom sync for synchronising Emacs with config changes, doom upgrade for upgrading, and doom doctor for fixing the messes you inevitably get into…

Since Doom is built on top of a Vim-layer for Emacs, it’s configured to use Vim keybindings out of the box. I’m not familiar with Vim, so I disabled this and used the Emacs bindings instead.

From Mouse to Keyboard#

The biggest shift from VS Code to Emacs was ditching the mouse.

This took quite a bit of getting used to, since I use the mouse for pretty much everything in VS Code: navigating files and directories, moving around inside files, working with plug-ins, working in the terminal - the list goes on.

Emacs works the opposite way: all navigation, in fact, pretty much everything, is done using the keyboard.

Emacs has a really good tutorial, which I worked through before diving in. The tutorial was a huge help, but I found navigating files and the Emacs editor in general really slow and difficult since the keyboard shortcuts weren’t muscle-memory yet.

Making a mistake could be overwhelming too, as all I was looking at were panes of text with no visual reference of where I was or what I was looking at.

This isn’t really a criticism - it came down to being unfamiliar with the Emacs workflow. Though I wanted to give up a few times and go back to the comfort of the graphical interface of VS Code, I persevered.

The day things clicked into place, I was able to move around the editor without a hitch, and the whole experience felt smooth — that moment of mastery felt incredibly satisfying.

Installing Extensions#

Once I had my environment set up and familiarised myself with the basics, I started diving into installing extensions — another part of Emacs that’s quite different from VS Code.

As I mentioned earlier, we’re spoiled in VS Code: if you can think of something to make your life easier, there’s probably an extension for it. Installing extensions is trivial too: go to the marketplace, search for the extension, choose the right one, and click install¹.

Installing extensions for Emacs can be a bit more involved.

Emacs has a few package managers, the most popular probably being MELPA. Package managers need to be configured, usually done in the .emacs/init.el file, which holds all the configuration for Emacs. Configuring package managers is pretty straightforward, but much like Emacs itself, can get complicated. Installing packages is a similar story.

Doom Emacs has a nice interface for installing common packages (called “modules”). Modules are installed by specifying the name in the init.el file. To actually fetch the module, you close Doom Emacs and run doom sync. Other packages are installed by specifying them in the packages.el file.

If a package can’t be installed through the init.el file in Doom, or you’re using vanilla Emacs, you’ll need to write some Emacs Lisp code to fetch, install, and setup the package behaviour. This can be… fun.

Conclusion#

Overall, I’m enjoying using Doom Emacs. I hate clichés, but it’s definitely true to say that Emacs takes a moment several moments to learn, but a lifetime to master.

I’ve found though the more I use Emacs, the more I am blown away by its flexibility. Also, having a Lisp dialect as the underlying language excites the programming language nerd in me.²

The biggest challenge? Changing the way I work. Emacs is text-based and keyboard-focused. Doom Emacs helps ease the transition with some handholding, but even so it takes time and persistence to resist reaching for the mouse.