UP | HOME

Emacs


To avoid rehashing articles that advocate for Emacs, I'll focus on how Emacs fits my specific work flow needs (or maybe how Emacs defind my workflow needs). The only two options I've considered for text editors are Emacs and Neovim. Both pass my criteria for software, but Emacs probably had the unfair advantage of being the one I used first.

Emacs vs. Neovim

The core difference is vi (and by extension Vim and Neovim) was built on the Unix philosophy of composability, while Emacs was built as a monolith. Neovim is just another tool in the toolbelt of shell commands and terminal applications. Its functionality is augmented by those tools, the terminal, and even the OS. Emacs, on the otherhand, is typically run in a GUI and generally relies on its own tools and packages to provide functionality.

But Why Emacs?

While I admit I'm biased towards Emacs, I have given Neovim a fair shot. The main reason I couldn't get it to work for me was the window and buffer management tools.

All text editors are fundamentally composed of these two primitive elements:

  • Window - a segment of the screen display that can be used to display text.1
  • Buffer - a container of text to be displayed.

The extent to which these two elements are composed varies greatly between editors, but Emacs and Neovim follow my preferred model of being relatively unopinionated in this aspect. They simply expose these two primitives and let the user decide how to compose them. Emacs normalizes almost all interfaces into this model which makes any workflows built on top of it more powerful and composable. Even the minibuffer can be exported to a buffer using Embark.

My workflow involves having between one to three windows open and switching between buffers in those windows. Using fuzzy search, I can quickly open a file or existing buffer in a target window and start editing. I use vterm to run a terminal emulator in a buffer, and it integrates seemlessly into the system. Complicated workflows like project-wide find and replace can be performed with a collection of tools (ripgrep, embark, and wgrep) since they all operate over the same text buffer medium.

This is where Neovim falls short for me, which is that it doesn't strictly hold to this model. Many interfaces are one-off windows with text content that isn't registered as a buffer. Most Neovim worksflows I've seen use either a tiling window manager or tmux to run a terminal alongside Neovim. This results in managing two separate windowing systems which greatly complicates workflows. When I tried Neovim, I only relied on the built in windowing system and terminal emulator, but found the whole experience to be somewhat inconsistent and frustrating to use. I spent most of my time trying to customize it back to feature parity with Emacs, so I just went back to Emacs instead.

Footnotes:

1

Text can also include other graphical content, but I'm primarily concerned with plain text