Text editors

The best thing since punchcards

I’ve used a lot of text editors. I like zipping around in a light 2-stroke text editor, as opposed to overengineered IDEs and word processors, both of 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 text editing actually is.

For a while I was using the text editor, atom, which is as free from IDE comforts as a dinghy is free from staterooms, and yet as slow and gigantic as any over-engineered 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 n absolute terms.

Here are some editors you might use, arranged in order of decreasing relevance to my own life.

Visual Studio Code

See Visual Studio Code.

Atom

See Atom.

Rstudio

An IDE for R that happens to include a passable text editor. 🏗

Sublime text

Sublime Text -- The UI-oriented cross-platform text editor that took 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.

I don’t use it, although perhaps I will.

IntelliJ

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

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.

Textmate

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

vi

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.

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.

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.

Miscellaneous others

  • xi is another hip cult thing, kind of a vim to Atom’s emacs in terms of simplicity (The worm turns.)

    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 clever is blogging lucidly about it. Since you have to install rust and xcode to compile it, there is no way that actually running this thing is anything other than yak shaving.

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

  • Notational Velocity – Text-oriented with excellent search

  • 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 should at least choose one with UX designers on staff and whose unrevised design does not predate the last 3 decades of accumulated user interface experience. From experience, emacs only stokes my weakness for yak shaving; and in any case I like my workflows less specialised than the exotic ones that flourish in the rich parenthetical mulch of the tropical emacsystem. See above re: IDEs etc.