2023.11.30
It’s kind of amazing, really. There are countless terminal text editors for Unix-like operating systems (and others), but most of them can be classified as one of three types; VI clones, Emacs clones and pico clones. At least that’s what I’ve gathered from all the research and experimenting over the years.
What’s interesting is not just the sheer variety of editors, but also how much people’s preference for one or another varies. New to the command line? Try nano. Do you like pain? Give vim a whirl. Want a second operating system? Here’s GNU Emacs. If those options don’t suit your fancy, try one of the many other editors. There’s ne, vis and micro… Hell, you could even have FIVE editors in one with joe! It emulates Emacs, pico and Word-star, while also providing two of its own flavours in just one binary measuring less than 1MB! Now that’s impressive.
What works for one person may be utterly ridiculous to another, as seen in the famous editor war. Some people just don’t care to think that much about it and choose one they like, based on the features and (most importantly) the user interface. That sounds like solid wisdom. So what do I need in a text editor? Honestly I wish this was obvious from the beginning as it could have saved so much time and stress.
The first time I used a command-line text editor was on FreeDOS, more than ten years go. There were a couple of them actually, one of which was RHIDE; the fancy IDE for DOS. This was also the first and ONLY time I tried GNU Emacs, but the weird key-bindings felt all sorts of wrong at the time. Years later when installing Void Linux, nano would become the default editor for a while since it was simple to use. I still have some documents that were written with it under termux and later on Void, as noted by a complete lack of consideration for text formatting. There are indentations everywhere, sometimes by multiple tab stops in a failed attempt to centre the headers. There is no wrapping of long lines, either…
Eventually I installed vim and learned the arcane ways of “the other bloated editor”. There’s no good reason for a CLI editor to use 10MB of RAM unless it was written in Go (such as micro). The smaller and simpler clone ‘vis’ was used for a while, but the lack of word wrapping was a major turn-off for me. Micro became the default near the end of my time in the Void, partly because it offered syntax highlighting and live spell-checking with error correction. You would be amazed how often I used it… Of course the key-bindings were a bit weird as I tried to make it similar to vim, but as a mode-less editor it took some time to break the habit of pressing ‘ESCAPE’.
Then the Raspberry Pi Zero became the daily driver, which meant not using micro unless it was cross-compiled (or operated remotely via SSH). Not wanting to put up with vim, I built and tested ne “the nice editor” under NetBSD. Now don’t get me wrong, ne really is a nice editor. It has a helpful menu and excellent documentation, but it felt like a pico clone and relied on GNU make to build it. I don’t like pico style editors, nor am I a fan of having to rely on gmake when I already have a ‘make’ command. There is no good reason to have more than one build system (like ninja, or its replacement “samuri”…). Personal opinions aside, I would definitely recommend ne for anyone who doesn’t like nano for whatever reason. It’s small but powerful, yet it doesn’t get in the way and is still very lightweight. In the end I just installed vim-tiny and stuck with that since I was already familiar with it.
After installing OpenBSD, there was a new sense of minimalism that led to trying other editors again. This was inspired by the presence of mg(1) in the base. I was hesitant at first, believing it to be inferior solely on the basis that it’s an Emacs clone. Upon asking myself why, I realized that somehow the word ‘Emacs’ in my mind has always been tied to the GNU variant, and probably that bad experience on FreeDOS. It was time to shed the old prejudices, so with an open mind I read the man page and gave it a whirl.