Code editors

The best thing since punchcards

November 12, 2014 — April 14, 2023

compsci
computers are awful
faster pussycat
plain text
UI
Figure 1

I’ve used a lot of code editors to edit a lot of code.

1 On loyalty

Editor brands, like programming languages, attract fierce loyalty from their users. Especially programmers tend towards committed pair-bonding with their preferred editor and if eventually they should terminate their relationship, the parting is often acrimonious and highly public, and there will be grievances aired in blog posts, and much complaining to friends about who was at fault, who looks are the children on weekend etc.

I have heard various hypotheses advanced about why this might be — aesthetics, Stockholm syndrome, philosophical entailments, elaborate procrastination… I personally tend to the notion that the culprit is a the descendent to Zawinski’s Law of Software Envelopment.1 This new law tells 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, and keyboard shortcuts can be reassigned by unaccountable third parties, and work computers can be reallocated by the whim of the organisational boss and so on, 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 that is the primary repository of your best habits and your muscle memory tricks and clever hacks and so on because you and it have a long co-evolution together 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 I am 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 was using the editor, atom, which is as free from IDE comforts as a dinghy is free from staterooms, and yet as slow and gigantic as any ocean liner, so I clearly don’t know what I want any more.

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 these my favourites, arranged in order of decreasing relevance to my own life. There are also special-purpose editors, e.g. for note taking.

Figure 2

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 happens to include a passable text editor, and a couple of neat features (equation preview!) and some misfeatures (bizarre/idiosyncratic keyboard shortcuts, no autosave…).

5 IntelliJ IDEA/Pycharm

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

6 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 also without any notion of what you are editing. While modern editors use clever integration into the language that you are editing to e.g. move your cursor to the function you wish to edit, vim has a more primal notion of navigating based on matching letters and lines and such that 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.

7 Kakoune

An attempt at a fundamentalist reinterpretation of the vi philosophy.

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.

Also I am 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.

8 Helix

Helix is somewhere between Kakoune and vim:

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

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

8.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).

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

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

9 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 specialised 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 in existing and continuing to exist.

10 Zed

Some authors of Atom started work on another hype editor called Zed. It aims to be collaborative-first, graphics accelerated and responsive, presumably at the expense of accessibility and extensibility? In beta. Not ?yet? open.

11 Sublime text

Sublime Text — The UI-oriented cross-platform text editor that got a lot of traction over when the guy 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, IMO, the best UI out 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 some guy who sounds terribly clever is blogging about it. This is a niche product with rapid drift and much manual installation required and for me at least installing it would be yak shaving.

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, in order to sell more CPUs.

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

14 Textmate

The ex from two exes ago.

Textmate — The brilliant-but-erratic Mac-OS 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, and they occasionally explode, and replacement parts can take four years to arrive.

Textmate I was using in combination with Atom, because there were some things it did 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.

14.1 Crashing Finder via quicklook

Posted because I don’t know where else to put it, since at time of writing (2018-03-29) the textmate bug tracker is closed:

Textmate was, for me, causing Finder the crash all the time, in a non-obvious way; Whenever I clicked on a binary file in Finder, it would crash. The crash log would include stack trees including _CTGlyphStorage, e.g. TRunEncoder::Encode(_CTGlyphStorage*, CFRange, unsigned int, __CFDictionary const*) + 280. This was from the preview rendering of binary files as text.

Turns out this is fixable.

# check if quicklook is buggering up your binary file:

qlmanage -p  ~/Music/bass.flac.asd
# qlmanage -p  /Users/me/Music/L…' terminated by signal SIGSEGV (Address boundary error)

# Delete
mv /Applications/TextMate.app/Contents/Library/QuickLook/TextMateQL.qlgenerator{,.disabled}
# refresh

qlmanage -r
qlmanage -p  ~/Music/bass.flac.asd
# no crash

When you next update Textmate your fix will be undone, but maybe it will be fixed in Textmate itself? Or you can delete TextMate.

Or maybe the problem is somehow specific to my computer? I don’t know, I’ve already spent all the time on this I can.

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. 🏗
  • BBEdit 14. After vi and emacs, the oldest editor that is still actively maintained is BBEdit, the 1992 classic which is actually not bad.

Footnotes

  1. I do not believe that Zawinskis Law applies any longer.↩︎