Don't use Vim for the wrong reasons (2020)

There were times, now and again, where I'd use vi, or vim, on solaris, or other "weird" systems. But basically I used vim for emails and emacs for everything else, and I think that was a good split.

Were I telling somebody to start a new editor these days I think I'd probably echo the recommendation to use the integrated tutorial, but after that just "jump in". gvim, emacs, and similar have menubars that help with many things before you learn the keystrokes required and there's no shame in using them. The article suggests learning and experimenting before switching, but to me that seems very counter-intuitive.

I found a lot of issues with trying to get a “good” setup, or got frustrated that moving from one job to another meant attempting to port my working setup to a new machine and new projects. I recently went back to NvChad and have done almost no custom config and I love it.

Do you know about :termdebug and what are you missing with it? It's just dbg hooked into vim, and you can use any other compatible debugger instead if you prefer, for example rr.

That's the beauty of vim, the tools you use are the tools you'd use in your terminal anyway.

The "counterpoint" is not that Vim is not _available_ on Windows. It is that Vim is not on Windows _out of the box_. You must install the native binary to have it or, like you suggest, install _another system_ on your machine… that actually comes with Vim.

"Can have X" is not the same as "has X".

FWIW, experimenting with Linux is also what got me hooked to Vim (and the shell and all the rest) in the first place, but rose-tinted glasses are not for me.

Here is how I think about it: the depth of these keyboard-based editors allows for a kind of progressive mastery and you decide how far to pursue it. Plenty of people use Vim in a very rudimentary way, barely using any of the features, and they still might prefer it. Others know certain slices of the functionality available, but everyone knows a different slice depending on how they want to edit. The point is it’s sort of an open space with lots of texture and customizability, which is sometimes how professionals like their tools. It lets you sort of build the tool into what you want it to be. And that can be true even without elaborate customization: even with a stock NeoVim install, figuring out over time which subset of features you care about is a kind of customization.

One tip I have: if you use VS Code, try the Vim extension. Or whatever IDE you use, see if it has a vim mode. That is by far the best way to learn, and it may well be the best way for you to use Vim long-term. You don’t have to change editors, you don’t have to configure anything, you can just focus on moving the cursor around in a new way.

The main drawback of all the keypresses you see is that Vim is an imperative editor: You have to tell Vim how to edit text by glueing together lots of small commands.* IDEs are declarative editors, you say "rename this variable" and they do it.

* Ask your local Vim nerd to rename the file they're editing. It will be entertaining!

I think maybe you shouldn't focus on the "productivity" - that's a fairly arbitrary metric, and difficult to measure - it often has more to do with how many bugs you have, how organized you are, and what you are trying to accomplish, how good friends you are with your boss/customer, and very little to do with which editor or what keybindings (or which language, even).

Instead, it is better to think about communication protocols - for a second consider something like the internet - something like handwaves, gestures, while theoretically analog and hence containing infinitely more data, they are very difficult to transcribe, send to the other side of the planet, and interpret.

I'm not saying these things cannot be done, but I imagine the internet would not exist if we had resorted to using thumbs up/down as our method of transferring information between "computers". We used a more appropriate, binary-based, protocol, and now we can send characters and have discussions! Maybe even include a couple hand-wave emojis!

Editors like vim/emacs are similar, they "feel" more productive because they are in some sense, "closer" to the code than a mouse can be. If I mainly am using a mouse (nothing else), then I probably should not be writing code at all and instead should be recording my program with hand waves, or something.

I'm not saying IDE's aren't useful, but that's because programming is neither about those mad FPS skills (mouse) or nor mad text editing skills, they are built to manipulate and mangle symbols, which is what we actually use (for better or worse) to program computers.

That's one reason why I find IDEs (often coupled with an emacs keybinding) mad "productive" - I can mash shortcuts all day long and most of my code writes itself (I'm not even using AI). I'm much closer to communicating with my code/debugger than having to mouse click around. Some of the transforms/translations are sometimes odd, or the UI environment is restrictive, so I'm using the mouse then for those situations. I often, frequently, find myself "out-coding" my peers.

But a good IDE is mostly aimed at being really good at modifying/generating symbols (in the context of a project). Its not very good at text formatting (usually handled by some plugin), for instance. And where it really falls apart, there's no control, i.e. usually it is a complicated product, with lots of pitfalls, speedbumps, "I screwed up and jacked my cache please restart me". And that nixes a lot of the "productivity" gained.

So that remains where a tool like vim/emacs/notepad++ etc shines, when you need to communicate with (roughly structured) text, they won't crash on you, they won't "get in your way", they won't need you to define an AST syntax in order to understand your little mini-language, and, at least of the extensible ones, you can define whatever it is you need or want to. IDEs are usually really, really bad at that sort of thing, if you find yourself needing to do that, you'll often 1) learn to cobble something together in a script 2) learn to cobble together something approaching that in an extensible editor 3) writing a language 4) writing a plugin to write your language in your IDE, to solve whatever it was....

- grab my mouse and click where I want the cursor, fix the typo, and then click back to where I was (or hit End, or was it Ctrl+Right? Opt+End?)

- type <Esc>Faa<Delete><Delete>ar<Esc>$

Ok, that’s a lot of weird keystrokes, but in my brain my hands just did “jump back to the a in ‘rae’, delete the ‘ra’, type ‘ar’, jump to the end of the line”.

Over a decade of Vim later and these motions are second nature to me, and using my mouse is usually reserved for the times I’m not in Vim. I can’t say I’m faster or more efficient, but I know how to get my cursor to exactly where I want it and how to manipulate, move, copy, delete, etc, in a way that feels natural and intuitive.

The biggest "productivity" changes for me in any IDE/Editor is the ability to fuzzy find for an arbitrary symbol, a keybinding to search for and subsequently open a file, LSP features like "goto definition", "find all references" (and jump back to where I was quickly) etc.

Thankfully I’m somewhere with sane tooling that watches for changes and only runs relevant tests, but back then this little foray into “how do I make Vim do a thing” saved me a ton of time.

No?

Some people want to know how to get IDE features such as errors, goto definition and type inlay hints into their editor of choice.

It's frankly hilarious to think that "it's only for bragging rights". It says more about you than anyone else.

Yes, you do. This is about how Vim integrates with the host terminal emulator and shell.

For example, make a key binding that moves between only functions that have a particular signature. Or a shortcut that takes heap snapshots, filters and format the output to your liking, and have it displayed alongside the source file with the suspected memory leak your hunting.

Otherwise no I still can’t get used to using j and k to move up and down even after a decade of vim.