In this post I’m going to talk about some old text editors you probably never heard of, what is modal text editing, and why people like it so much.

Modal Text Editors

Like some of you, I got interested in programming fairly young. I started messing around with TurboC¹ when I was a teenager, arguably, my first experience with an editor running in a “terminal” (MS-DOS).

I remember it being a really weird experience, as so far I had only used Notepad.exe to write some HTML.

Later on, I started learning some Linux, and had my first encounter with Vim (or Vi, can’t remember). I had to search on the internet how to use it, and this was at the time where you would ask pretty much anything and someone would RTFM you. I felt really dumb.

And that was my first experience with a modal text editor.

A modal text editor has multiple modes of operation, and the keys’ functions change depending on which mode it is in. While TurboC and nano aren’t modal text editors, Vi and Vim are.

Without further ado, let’s get into the history.

Ed - The Standard Unix Text Editor

In 1969, Ken Thompson, co-inventor of Unix, released Ed.

It was a line-oriented text editor, but it didn’t look like a text editor - you couldn’t even read the entire file and scroll it like we can do today:

Not very user-friendly, I agree.

The usage kinda make sense once you know it, though: You’d type a to go into insert mode and append some text to the file, then CTRL+D followed by Enter to go back to command mode. 1p would print the first line, w would write the file, q would quit, and so on.

Still, I find it impressive that people used this to write software for many years.

Ex - The Extended Text Editor

Derived from Ed, Ex was released, almost 7 years later, in 1976. It was created by Bill Joy, co-founder of Sun Microsystems, you know, that one that created Java and Solaris.

It still had the line-oriented commands like Ed, but it also had an innovative visual mode:

Vi - Visual Interface

Vi was released together with Ex.

Basically, vi was the :visual (or simply :vi) mode within Ex, and Ex is a mode within vi as well.

💡 The attentive reader might have noticed that the initial screen of vi in the gif above says Vi Improved. That happens because vi is, usually, a symbolic link to vim:

$ ls -lha `which ex` `which vi` `which vim` `which ed`
.rwxr-xr-x 235k root 15 Jun 07:08 /bin/ed
lrwxr-xr-x    3 root 15 Jun 07:08 /usr/bin/ex -> vim
lrwxr-xr-x    3 root 15 Jun 07:08 /usr/bin/vi -> vim
.rwxr-xr-x 5.3M root 15 Jun 07:08 /usr/bin/vim

Unfortunately, I couldn’t find a way to run “the actual vi” locally, as there’s no packages on any OS/Docker image I tried.

It lacked a lot of features, though.

For instance, it didn’t had a file tree or explorer. What if you wanted to see the files in the current directory? You simply needed to type !!ls ., and the files will be listed in that buffer.² From there, you can search files (using /) and open them by prefixing the line with :e, yanking it with yy, and typing :@" to execute the command.

Easy. 😉

Vim – Vi Improved

In response to the limitations of Vi, in 1991, Bram Moolenaar³ released Vim.

Notice this happened 15 years after Vi was released. Vi was popular for many years, and Vim built on top of that by adding many features: multiple windows, splits, tabs, better syntax highlight, completions, support for customization via Vimscript, plugins, macros, multiple clipboards, a file explorer, and much more.

Nowadays, vim comes pre-installed in most Linux distributions and in macOS.⁴

Usage is basically the same as Vi, but a bit more user user-friendly, since you can install plugins to facilitate common tasks (like a fuzzy finder, for example).

Neovim – Hyperextensible Vim-based Text Editor

Neovim, the latest of the lineage we’re exploring today, was released in 2014 - more than 2 decades after Vim. It was created by Thiago de Arruda, a fellow Brazilian 🇧🇷.

It is a drop-in replacement of Vim. Most Vim plugins are compatible, and the editing model is the same.

Some of the advantages of Neovim are:

• using Lua as configuration language (arguably easier/better than than Vimscript, opinions vary)
• native LSP and Treesitter integration
• job API for multi-tasking/async
• better default settings
• integrated terminal (again, opinions vary)

All that makes Neovim feel a bit more modern, while maintaining the performance and features Vim users love.

Why you might have never heard about them

I think most people would agree that modal editors are harder to use than “normal” text editors.

Vim’s editing model is rather complex, and the learning curve is steep. It’ll probably take you days to get comfortable with the basics⁵, like the movements, saving, quitting, search, etc. For instance, if you search for “vim cheat sheet”, you’ll find things like this:

Most of the images you’ll find contain tons of information, but are still missing features, as well as pretty much all the configuration options.

Vim is so unintuitive for the non-initiated, that failing to quit it is a running joke in the field, for decades.⁶

Giving this steep learning curve, and the fact that most professions probably won’t use most of its features, its rare to get recommended Vim if you are not in the software industry.

On the other hand, “regular” text editors are much more intuitive, and the learning curve is much smoother. You open them and can immediately do basic text editing: Select with the mouse (or Shift and arrows), navigate with the arrows, and backspace and delete just work as they do outside the editor.

This user-friendliness and lack of surprises is the reason you usually get recommended⁷ non-modal text editors (say, VS Code) instead of Vim.

Incidentally, you were never recommended Ed, Ex, or Vi because you’re too young, probably.

Why people still love them

Once you pass the steep learning curve barrier, you’ll immediately feel more productive than you would in a “normal” text editor.

I think that’s the major reason why people love it: they feel more productive.

But its not just about productivity. Other reasons people usually give include:

• low resource usage
• better performance
• “muscle memory” for those using it for many years
• it doesn’t get in your way
• more customization abilities
• macros
• never using the mouse while coding, ergonomy
• its wildly available
• being able to stay at the terminal most of the time while working
• you’ll learn more about the tools you use
• being able to say “I use vim, btw 😎” (huge flex)

All that is why people still use and love Vim, and it’s why it is probably never going away.

Getting started with Vim/Neovim

I think here there are usually three personas.

Persona 1: Wants to go really slow, or wants to learn Vim motions only

If you want to start slow, run vimtutor, and install a Vim plugin in your current editor.

Persona 2: Wants something that “just works”

You’re probably looking for a distribution, and lucky you, there are many to choose from.

Some examples:

• AstroNvim
• LazyVim
• Lunarvim
• NVChad

I have never used any of them, so I can’t do any specific recommendation here. Also there are probably more distributions than that.

Start with vimtutor, then install one of these, learn how the shortcuts (usually they have them documented), learn how to use marks, quick fix lists, …

Persona 3: The hardcore

If you want to really learn it the hard way, start with vimtutor, then open Vim/Neovim, and start itrying to configure it as you’d like. You might need to learn some Vimscript/Lua as well.

This is definitely the hardest way to learn Vim, but in my opinion, also the one that will give you more complete understanding of what’s going on.

There is a Neovim subreddit, a lot of dotfiles on GitHub, the sources of the distributions listed above and much more.

This is what I did, and after a couple of months my configuration is pretty much stable now, I find myself removing more things than adding, usually.

---

That’s it

A different kind of post, I know.

The full story here is that I took some oratory classes, and in the last day I had to talk about something for ~10 minutes.

They had a preference for it to be something work-related, and since I was the only programmer there, I tried to find something I could explain in in the time I was given and, more importantly, something I wouldn’t have to give a lot of context about first. Bonus points if it was at least mildly interesting for them.

This post is what derived from my first drafts of the talk, adapted to the audience.

Anyway, I hope you enjoyed it, see you in the next one.