Code editors

1 On loyalty

Editor brands, like programming languages, attract fierce loyalty from their users. Programmers especially tend towards a committed, pair-bonded relationship with their preferred editor. If they eventually terminate their relationship, the parting is often acrimonious and highly public, with grievances aired in blog posts and much complaining to friends about who was at fault, who looks after the spawned sub-processes on weekends, etc.

I have heard various hypotheses about why this might be—aesthetics, Stockholm syndrome, philosophical entailments, elaborate procrastination… I personally incline to the notion that the culprit is a descendant of Zawinski’s Law of Software Envelopment.¹ This new law says that any hackable editor used by programmers will eventually turn into a full-fledged interface to your OS that you use for basically all interactions with your computer. To see this in full bloom, consider what four decades of emacs habituation hath wrought.

This seems to me to be a natural response to the fact that while OSes and computing platforms come and go, keyboard shortcuts can be reassigned by unaccountable third parties, and work computers can be reallocated by the whim of an organizational boss, no one can take your preferred text editor away from you; they must pry it from your cold, dead fingers. A coder’s choice of editor is usually regarded as intimate as their choice of underwear, and as far outside the purview of the boss—which is to say, not always as far outside that purview as it would be in an ideal world, but it is wildly inappropriate to mess with it. As such, it’s completely reasonable to become absolutely committed to this app, which is the primary repository of your best habits, muscle memory tricks, and clever hacks, because you and the editor have co-evolved and know how to keep each other happy.

I also like this model of why we care because the metaphorical corollary is that, much like business and romantic partnerships, editor-coder partnerships are essentially individually specific, arbitrary, and taste-driven. There is no universally appropriate editor. I love my spouse, but that does not mean that everyone who does not love my spouse is wrong or that I should go on to Reddit to say so at length.

FWIW, I like zipping around in a light 2-stroke code editor, as opposed to over-engineered IDEs which make me feel like a stowaway trapped in the bilge of someone’s supertanker. There are many options, which is surprising given how hard editors actually are.

For a while I used atom, which is as free from IDE comforts as a dinghy is free from staterooms, yet as slow and gigantic as any ocean liner, so I clearly don’t know what I want anymore.

Now I am using Visual Studio Code, which is faster and better, in a startling change of direction for Microsoft. Although it is still gigantic and slow in historical terms.

Here I list some general-purpose editors you might use, including my favourites, arranged in order of decreasing relevance to my own life. There are also special-purpose editors, e.g. for note taking.

2 Visual Studio Code

My current squeeze. See Visual Studio Code.

3 Atom

My ex. See Atom.

4 Rstudio

My unwelcome stalker. An editor/light IDE for R that includes a passable text editor, some neat features (equation preview!), and a few misfeatures (bizarre/idiosyncratic keyboard shortcuts, no autosave…).

5 Zed

See Zed.

6 IntelliJ IDEA/Pycharm

IntelliJ etc. are really full-featured IDEs rather than text editors, but these two categories are increasingly blurring together. TODO.

7 vi/vim/etc

My first love. We still see each other occasionally.

These days we spell it vim or neovim, but the idea is the same. A fugly, quirky, functional, no-fuss editor that runs everywhere, most notably your legacy campus computing cluster.

“The bartender’s smile widened. His ugliness was the stuff of legend. In an age of affordable beauty, there was something heraldic about his lack of it. The antique arm whined as he reached for another mug. It was a Russian military prosthesis, a seven-function force-feedback manipulator, cased in grubby pink plastic.”

I am sure that William Gibson was thinking of vi when he composed the above quote, since vi was already about 4 years old by then.

For me, the best trick is the many cunning ways it allows you to navigate text without the mouse and without any notion of what you are editing. While modern editors integrate cleverly into the language you are editing—for instance, to move your cursor to the function you wish to edit—vim has a more primal notion of navigating based on matching letters and lines, which is more robust and universal than any of that modern fanciness.

There is a 3d version.

An effective manual is History and effective use of Vim. Learn VIM while playing a game in VIM Adventures. See also various successors and derivatives such as martanne/vis: A vi-like editor based on Plan 9’s structural regular expressions, and spiritual heirs such as Kakoune and Helix.

8 Kakoune

mawww/kakoune is an attempt at a fundamentalist reinterpretation of the vi philosophy in C++.

Multiple selections are the central way of interacting in Kakoune, with powerful handling primitives (regex matches, filtering, splitting, aligning, text objects etc). Text can be selected and modified at will in multiple ways, thanks to several primitives: selection rotation, case manipulation, indentation leveling… With Kakoune, you can collaboratively edit the same file: all new windows created by the editor are clients, and can simultaneously modify the content of a file. As such, windows are fully under the control of your X11 window manager or can be managed in a single terminal through Kakoune’s tmux support.

I am also fond of the following design points

• No threading: multithreading is a hard problem, and is not well suited to a text editor: Either we want a direct result, and we need to be synchronous with the user, so getting a 4x speed up is meaningless, we need to have an algorithm which appears instantaneous the user. Or we want an asynchronous result, and then the processing is best left to a helper command which can be reused with other Unix tools.
• No binary plugins: shared object by themselves add a lot of complexity. Plugins add another interface to Kakoune, and goes against orthogonality. The %sh{ ... } and socket interface should be made good enough for most plugin use cases. It is better to write Kakoune-independent helper tools (intelligent code completer, source code navigation programs) that can interact with Kakoune through the shell than write them in a plugin.
• No integrated scripting language: for the same reason as binary plugins.
• Limited smartness: Kakoune should not try to be too smart, being smart is often unpredictable for the user, and makes things context dependent.

9 Helix

Helix is somewhere between Kakoune and vim—in other words, another schism in the interpretation of the minimalist creed. It is written in Rust, which is always its own schism.

• multiple cursors as a core editing primitive, inspired by Kakoune. Commands manipulate selections which allows concurrent code editing.
• Tree-sitter produces error tolerant and robust syntax trees, which enables better syntax highlighting, indent calculation and code navigation.
• Navigate and select functions, classes, comments, etc and select syntax tree nodes instead of plain text.
• Language server support: Language specific auto completion, goto definition, documentation, diagnostics and other IDE features with no additional configuration.
• Built in Rust, for the terminal. No Electron. No VimScript. No JavaScript. Use it over ssh, tmux, or a plain terminal. Your laptop battery life will thank you.
• Modern builtin features Fuzzy finder to jump to files and symbols, project wide search, beautiful themes, auto closing bracket pairs, surround integration and more.

9.1 Are there plans for a GUI frontend?

Eventually, yes! We’d like to prototype a WebGPU-based alternative frontend. See the tracking issue on GitHub.

9.2 What about plugins?

While there is currently no plugin system available, we do intend to eventually have one. But this will take some time (more discussion here).

9.3 How does it differ from Kakoune?

Mainly by having more things built-in. Kakoune is composable by design, relying on external tooling to manage splits and provide language server support. Helix instead chooses to integrate more. We also use tree-sitter for highlighting and code analysis.

9.4 How does it differ from Vim?

By starting from scratch we were able to learn from our experience with Vim and make some breaking changes. The result is a much smaller codebase and a modern set of defaults. It’s easier to get started if you’ve never used a modal editor before, and there’s much less fiddling with config files.

10 emacs

I am contractually obliged to mention emacs, but if I need an over-engineered editor with a horrible scripting language I can already get that from Visual Studio Code, and they throw in a superior UX for free. In any case I like my workflows less specialized than the exotic ones that flourish in the rich parenthetical mulch of the tropical emacsystem. But if this aesthetic speaks to you then I will not stand in your way. Also if longevity is a concern, emacs has an excellent track record of existing and continuing to exist.

11 Sublime text

Sublime Text — The UI-oriented cross-platform text editor that gained a lot of traction when the person who made the previous trendiest text editor (TextMate) went AWOL for 3 or 4 years. I feel bad for the creator, who held the text editing world together solo for years with a genuinely impressive product and now has all these free competitors backed by large corporations, drinking his milkshake. Still has, in my opinion, the best UI of everything. Seems fast too. I don’t use it.

12 xi

xi is another hipster cult cognoscenti thing, kind of a vim to Atom’s emacs.

The xi editor project is an attempt to build a high quality text editor, using modern software engineering techniques.

This is to say — it uses sensible data structures and is written in Rust, and someone who sounds terribly clever is blogging about it. This is a niche product with rapid drift and much manual installation required; for me, at least, installing it would be yak shaving. Deprecated in favour of lapce.

13 LightTable

LightTable — pretty, open source, revolutionary IDE-like live-code inspection. Language support is deep but narrow. (clojure, javascript, python). There is an effort to port it to an Atom-like architecture to sell more CPUs.

I used this while I was learning clojure, but that project is on hiatus now.

14 TextMate

The ex from two exes ago.

TextMate — The brilliant-but-erratic macOS editor that the Rubyists used to use. Now open source, but with an intimidating code base that few seem to want to touch. Famous for painstakingly re-inventing wheels that look nearly exactly like the old wheels but nearly imperceptibly rounder; they occasionally explode, and replacement parts can take four years to arrive.

I used TextMate in combination with Atom, because it did some things better than Atom (search, tab-triggered macros, not using all your RAM), although TBH TextMate was not really fast enough. Anyway, now VS Code fills both niches.

15 Incoming

See also various specialist note-taking editors.

• jupyter is also effectively a text editor with built-in preview. I use that function sometimes when its many inconveniences are outweighed by its interactive code execution, which is increasingly rare.
• Brackets — Adobe’s web-design-centric editor, with the best CSS support out of anything. (If you are going down this webbish path, make sure to use Emmet too) Adobe has discontinued support in favour of VS Code.
• HackMD is a collaborative online markdown notebook targeting open-source ventures. 🚧TODO🚧
• BBEdit 14. After vi and emacs, the oldest editor that is still actively maintained is BBEdit, the 1992 classic which is actually not bad, albeit not especially distinguished.