Code editors

The best thing since punchcards


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

On loyalty

Editor brands 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.

People make claims about why this might be – Aesthetics, Stockholm syndrome, philosophical entailments, elaborate procrastination. I personally tend to the notion that the culprit here is a cousin to Zawinski’s Law of Software Envelopment which 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 habituations hath wrought. 1 This seems to me to be 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 universally as far outside as it would be in an ideal world but it is wildly awkward 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 my 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 overengineered IDEs which make me feel like I am a stowaway trapped in the bilge of someone’s supertanker. There are many options here, 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. Perhaps simply to be loved.

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 absolute terms.

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

Visual Studio Code

My main one. See Visual Studio Code.

Atom

My ex. See Atom.

Rstudio

My bit on the side. 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 and idiosyncratic keyboard shortcuts, no autosave…). 🏗

vi

My first love who I still see occasionally.

These days we spell it vim or neovim but the idea is the same.

“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.”

A fugly, quirky, functional no-fuss editor that runs everywhere, most notably your legacy campus computing cluster.

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.

It has some excellent tricks. For me the best one 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.

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 here. Seems fast too.

I don’t use it, although I am sure it is great.

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 a little bit rounder, although they do occasionally explode and replacement parts can take four years to arrive.

Textmate I was using in parallel with Atom, because there were some things it did better than Atom (search, tab-triggered macros, not using all your RAM) although TBH it could still be faster. Anyway, now VS Code fills both niches.

Crashing Finder via quicklook

Posted here 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.

IntelliJ

IntelliJ is more of an IDE than an editor, but I hear it recommended enough by editor types that I feel I should mention it tokenistically.

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.

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.

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’ve used this while I was learning clojure, but that is on hiatus now.

Miscellaneous others

See also various specialist note-taking editors.

  • jupyter is also effectively a text editor with built-in-preview. I use that sometimes when its many inconveniences are outweighed by its integrated code.
  • 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)
  • HackMD is a collaborative online markdown notebook targeting open-source ventures. 🏗

I would mention emacs, but if I needed a bloated and confusing editor with a badly-considered scripting system, I’d run atom, for, in that case, I would at least have chosen one with UX designers on staff and whose unreconstructed design does not pre-date the last 3 decades of accumulated user interface experience. 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 of course, there is no accounting for taste.


  1. The same applies to programming languages but that is a story for another time.↩︎