Text editors

Given that computer code as a medium is very simple — a bunch of plain text files — it’s amazing how complicated applications for writing it are.

You could write code using Notepad on Windows or TextEdit on a Mac, or something even more basic, and that code would work as well as if it was written in a more advanced application.

While you could also write a novel in Notepad, instead of Microsoft Word, with Word you could get a different output: fonts, styles, formatting, headers and footers, etc. But, when it comes to code, the output of Notepad and, say, Visual Studio Code will be the same. Plain text, readable in anything.

Code-writing applications are complicated because of their tools to improve the process, rather than the output: syntax highlighting, linting, autocomplete, version control integration, automatic indenting, formatting, brace matching, folding, regular expression search and replace, multiple selections, debugging tools, tabs, panes, overviews, file browsers… so many things.

Even though most text editors will share most or all of the same headline features, every feature is so complicated, with so many variations of implementation and user interface, that there’s are many very slight differences between each editor. This editor does that thing better, but that one has this little feature.

On top of that, most editors have hundreds of extensions that can be installed to add further features or improve existing ones.

On top of that there are all the ways of configuring an editor to tweak its interface and how it works. My copy of Visual Studio Code, with a few extensions added, says it has over 800 settings for me to alter.

Even tiny alterations can make an editor more or less frustrating when you’re used to something else. Try to select a whole word and find that this editor thinks a hyphen is part of a word, rather than separating two words? Ugh! Into the settings you dive.

Over the past 25 years or so of using Macs I think my journey from one text editor to another has been something like:

All of these are still around and all are more than adequate for writing code in. I could have been using nothing but BBEdit for the past 25 years and my code wouldn’t be any worse. It might even be better because I wouldn’t have spent time learning and reconfiguring a new tool every few years.

Early on I think I changed editor mainly for the sake of change, to try something new. Maybe they even offered new features my existing editor didn’t have.

But then the (first) switch to MacVim was perhaps the biggest change. Vim (the editor behind this Mac-based version of it) is very old. Its interface is designed to be used without a mouse, and it has a steep learning curve involving memorising key commands. In use, you switch back and forth between two modes: what you might think of as a “normal” one in which you can type things and one that is actually called “normal” in which hitting keys in various sequences will perform various commands.

For example, typing 3dd5jp would delete the next three lines, move down five lines and paste in those lines I deleted. Unless I was in the wrong mode, in which case I would end up with 3dd5jp typed into my document.

This is a ludicrous idea and while fans might tout the speed at which you can, eventually, work — no pausing to find the cursor and use the mouse/trackpad — I am doubtful any vim user has saved more time than they invested in learning how to use it and then laboriously configuring and extending it to their own liking.

And yet, I keep coming back to it, now the basic handling of it is in my muscle memory. Once the basic keystrokes are as ingrained as any of the others we take for granted (cmd-w to close a window, cmd-c to copy, etc.) then having to rely on a mouse does feel slow and clunky. Both Atom and Visual Studio Code offer vim modes that attempt to mimic its peculiarities which made it easy to flirt with them while not having to change my fundamental habits. Which sounds like a terrible excuse for an affair and they didn’t mean anything to me, honest.

I tried Atom because it seemed newer and prettier than MacVim (see!) and I’d recently had a struggle trying to set up a couple of complicated vim plugins. The first time I tried Atom I wasn’t quite hooked, but a year or two later I tried again and it stuck for a while. Configuring it was easier than googling for vim’s obscure text-based settings and its extensions were easier to find and install. But it wasn’t perfect. It seemed sluggish at times and its ability to find-and-replace text was, and still is, often buggy.

This year I noticed two or three friends whose tastes I respected were using Visual Studio Code so I gave that a go. From my perspective it’s not radically different to Atom but it did seem a bit better. Extensions were, perhaps, even easier to install and set up, and it felt faster. But, again, some things were frustrating and couldn’t be fixed with all those settings. Find-and-replace involves small windows hovering at the top-right of the window, sometimes obscuring the text behind, and its various option buttons (case-sensitive, replace all/one, etc.) are very tiny. Oddly, Visual Studio Code also suffered from a similar problem with its find-and-replace to Atom.

It also had a habit of not-quite-freezing-up several times a day (which, to be fair, could be due to an extension rather than the application itself). For a couple of minutes I could do everything except type text. So I metaphorically threw it out of the window (to clarify, we have moved on to a different metaphor) and went back to MacVim.

Of course, now it’s been a while since I used MacVim and there are so many new things I could add and tweak. I read some blog posts and have spent half the weekend trying out plugins and attempting to configure things. This is a ridiculous use of time. MacVim is still, in many ways, worse than Visual Studio Code, Atom, or probably any of the other options. There are things it can’t do, or I can’t make it do, or that it does slightly worse or in a more ugly fashion. And yet… it feels snappier and I quite enjoy the arcane fiddling with a text file full of settings.

Years ago I used to enjoy spending time fiddling with my computer. As Brent Simmons mentioned the other day, there was a lot of fiddling that one could do with a Mac:

HyperCard, AppleScript, and UserLand Frontier. ResEdit. INITs. All this crazy powerful stuff, which I loved.

That’s a bit less possible now but also I have less inclination to do so. Most of my computer is fine, just fine, and I’m happy if it simply keeps working and if periodic system upgrades don’t change anything I currently use.

Working on my MacVim settings (which you can find on GitHub) feels a bit like all that fiddling used to. It takes longer than is reasonable, given the results, and it’s more complicated than should be necessary given software today. But the act of figuring things out and struggling to customise something is, eventually, pleasurable in itself. Tinkering for the sake of it.

I may well end up trying a different editor again in a few days or weeks or months. I’ve yet to find a nice way of searching multiple files in MacVim (“But,” I think, “maybe if I install Silver Searcher, and ack.vim to replace the deprecated ag.vim… do I also need fzf.vim…?”). And, after my time with Atom and Visual Studio Code, I’ve become accustomed to using tabs which doesn’t really happen in MacVim (its buffers and tab pages are things I’ve never got to grips with). And, while MacVim is nippy it still looks rather… unrefined.

Maybe I should cycle back round and try BBEdit again. It’d be nice to have something completely fresh — it would need so much customisation. What fun!