Text Editing Improved

Where I found Vim

I remember a time before I used a text editor, and when I didn’t know that plain text and formatted text were two distinct and different things. I didn’t start using Vim until after I had been introduced to IDE’s such as Visual Studio and Eclipse. I had even learned about other (albeit heavier) text editors; Sublime, Atom, and Notepad++ were all introduced to me, the University Student with a Windows Laptop.

Something unexpected must have happened once I had to regularly use the University network resources. Often in these ‘lab’ classes (since you don’t have to go online, you just need to have a network connection to the lab), you’re expected to either set up an FTP connection to upload files to your sandbox, or if you’re not fond of writing, uploading, running and then finding out that you messed something up somewhere you’ll probably look into the SSH option.

If you’ve never used a Linux machine over SSH, you’re not living. You get to peer back into the norms of the past — no graphical user environment, no mouse, only your keyboard, a terminal screen, and several cryptic phrases you can type to get more info. Once you start to grok it, you begin to feel like you really are a hacker.

On those Linux machines you’re given two real options, nano and vim; vim was always sated to be the more difficult option, but I found that I was able to also get a Vim installation on Windows, and also Vim was actually everywhere. Some of the lab machines weren’t installed with nano, so eventually you had to learn Vim. And once I did, I really fell in love.

The Real Way I Met Vim

My remembrance of meeting Vim is probably apocryphal; really I probably encountered it the same as a lot of other people learning to code in the mid 2010’s, while also learning git. The default text editor for command-line git is usually Vim, and you’re not really told what that means from the install. So when you run git commit your first time, you’re kicked out to a screen with text telling you what the git commit spec expects. But Vim wants you to either press ‘i’ or ‘a’, and if you don’t know that, good luck. Even if you know things about the command line and try to quit; Ctrl+c, Ctrl+x they don’t work! Instead you’ve summoned a message telling you to use :qa to quit.

This happened at University for me, so my need to know why was already being stoked, but I’d imagine this not uncommon first experience with Vim probably turned many new users away. It’s understandable, but I can’t imagine not using Vim as my text editor.

The Other Text Editors

I started using Vim consistently when I had to use SSH to Linux machines. It is one of the ubiquitous text editors, the other being nano. At my University, whenever you’re working SSH you’d almost always be encouraged to use nano. Nano uses the arrow keys, and it’s instructions are always visible at the bottom - it’s much more new-user friendly.

Note, I didn’t call out Emacs as “ubiquitous,” and that’s because as far as software installed on distros, it’s not common. I’ve almost never been told after trying to run Vim on a Linux box I didn’t know that it didn’t have it.

Nowadays, the text editor market is flooded by GUI clients; Sublime, Atom, and Visual Studio Code. All are fairly serviceable pieces of software, but I didn’t fall in love with any of them like I did with Vim.

Just Type

One of the things I love about Vim, is that I don’t move my hands when I type. To write something, I hit “i” and start typing. To search for something I hit “/” and type what I want to find. To make a macro, I hit “q” then pick the macro name then I make it.

Whenever I try a graphical text editor, I find myself getting frustrated that I have to keep taking my hands off the keyboard to move, or search, or open a new tab. It takes me out of it, and Vim doesn’t have that problem.

Plugin Ecosystems

Some text editors are propped up on plugins, and extensibility. In the Vim community there is a bit of a debate about whether or not massive extensibility is worth it. Many power users don’t like the “bloat” and “cruft” of adding on a patchwork of plugins. Other users want Vim to look like Visual Studio, and want full-text search on arbitrary files with auto-completion from APIs. Both are totally possible and valid, although I think keeping your config simple is its own reward. Vim has plugins in spades, and I’ve almost never found that I needed something that wasn’t available.

Massively Hackable

For the rare instances where a plugin can’t help you, Vim has features and extensions that can allow you to build your own tools. Usually the things I need can be covered in a quick macro, but the possibilities are honestly endless. Vim has APIs for most popular languages so your home-brew plugins can be written however you like. This isn’t even mentioning the vim-specific Vimscript, which is a fully fledged scripting language that lets you work with the editor in the same way that the user interacts with it.

Other text editors have come out saying that they have a ‘hackable’ interface, but they always seem to block anything in the back end or they’re written on-top of a platform that doesn’t really let you do literally everything. Vim opens up the inner mechanics of the editor to the user (if they want it), and you feel like you can really make this machine act the way you want.

Even better, I’ve found the vim manual (“F1” or :help) is written in a way that makes finding the answers to things easy, and finding the questions you might not have even known you wanted to ask reveal themselves. I started learning vim through tutorials, and Stack Overflow, and now I usually try to learn things via the built-in manual; I find it that helpful.

A Better Way to Write

The lead developer and “BDFL” Bram Moolenaar has written about why Vim is designed the way it is, and I guess I’m a convert to how Bram sees text editing. The first insight that we get from Bram’s piece “Seven habbits of effective text editing” is that most people spend more time editing text than writing it. This didn’t really click with me until I read this piece, even though I had been using Vim for over 2 years. It’s why you can’t put text down in “normal mode,” because normally you aren’t writing — you’re editing, finding info, and moving or removing text.

The #1 thing that Vim provides that most editors don’t even think about, is this modal system. There’s a distinct difference between writing and editing. Editing is a lot of reading, moving, marking and deleting. Adding text is just that: you write a bit of text, and then you call it a day (and probably go back to editing). Most other editors have you constantly working in the “write stuff” mode, and the editing functionality is sprinkled on top. To find stuff you hit “CTRL+f” and type something in, usually to a totally different context, then maybe you hit “F3” or you have to click on a button. For Vim, you go to normal mode “esc” hit “/” type what you want to search for, “Enter” and you’re now searching for that word, still in normal mode. You can cycle through by hitting “n” or “N”. I like this a fair bit more because:

1. there are no chords, or having to hit 2 keys at the same time
2. the “Find the next one” is on my index finger, just one row down
3. I don’t have to open a new context or window to search - it’s still in the same window.

If you haven’t read the “Seven habbits of effective text editing” I’d give it a read. Maybe it’ll spark some curiosity in Vim. I find that after making the modifications that I’ve wanted to Vim, it’s hard to even think about picking up any other text editor.

About That Learning Curve

In any time after 2010, Vim’s controls are cryptic. The manual I just praised is hidden away, and in most installs of vim, you don’t really have a menu where most applications might lead you to those things. After you press “F1” you might be good to go, but I have never met anyone who’s found that on their own. Even though it says how to access the help on the start screen, many first time users don’t read.

Vim’s learning curve is relatively steep, but adding a lot of the things that might smooth it out would almost break the core ethos of vim. Add a menu bar and now you’re being told to use the mouse, which is really the antithesis of Vim. Start in “insert” mode and now… how does the user know how to get out? Let “Ctrl+x” and “Ctrl+v” be cut + paste… and now you obfuscate that you can store as many strings as you can in named buffers. Vim’s got a lot of features that were put there because people using it every day found they were being inefficient and they could hack it. Looking at Vim, you can tell it wasn’t designed by a committee, or a UX board didn’t say how the start screen should look. It was built by people who used it.

Epilogue

I’m a huge fan of Vim; it’s the best piece of software I’ve ever had to use, and I don’t see myself moving off of it for another piece of software any time soon.