vi also builds its concepts together in a great way. Navigation keys are powerful, but combined with actions, they become monumentally powerful in a way few IDEs seem to replicate well. Something simple like "copy the next 10 lines to the clipboard" is just 10yj or 10Y or even y10j. No awkward reaching for control keys. Now combine those actions into macros and things get really fun.

One of the most fun navigation keys is the under-reported "f" key. If the cursor isn't where you want it to be, you can easily put it on the right line (perhaps with 55G or something if you want line 55) and then to move the cursor over the character you are actually looking at you just type f( assuming that ( is the character you want the cursor on. It's just great... it's about having the computer work around your human experience of looking at the screen in a nice way.

> One of the most fun navigation keys is the under-reported "f" key. If the cursor isn't where you want it to be

There's also the t key which will place the cursor on the character just before it. There are also the F and T keys that will search backward in the same line and the ; and , keys that allow you jump from character to character in that line.

But, if you want more flexibility and the ability to jump across multiple lines, a / or ? search will allow you to select text up to and including the multiple characters you search for.

There are so many navigation keys and combinations, that's kind of what is great about it. A lifetime's worth, in the case of vim and neovim. I personally have got a lot of mileage out of f, F, t, T, /, ?, G, 0, W, w, e, E, b, B, }, and %.

Unfortunately, the barrier I faced with even trying VI is that you cannot discover any functionality intuitively. Exaggerating (but just a little) I could not even figure out how to type without someone giving me a tutorial. That was enough to make me stop.

I agree. You need to use vimtutor to get the basics: the simplest modes (insert, normal), the simplest normal-mode motions (hjkl), the simplest normal-mode actions (d, c, f/t), and the concept of "adverbs" (8j, 4dw, 2df]).

Once you have mastered these simple concepts, most of the magic comes from (1) combining them (2) googling the things that you intuitively know must be possible, and discovering how they're done, which in turn gives you more basic concepts.

At that point, your feedback loop gives you escape velocity, and you'll never willingly go back to a standard text editor again. :)

Getting escape velocity is really tough, though.

For me, learning came when I was on an IBM RT/PC (pre RS-6000), in something like 90 or 91. I used IBM's editor from the console, but one time I had to edit something from a terminal back in the shop. Which didn't have full support for the IBM editor (Ined I think it was called), due to the way the keyboard was mapped. Something about left cursor was the same as backspace (ctrl-h).

Well, that did it -- I went back to my desk, and pulled up vi-tutor.txt, then never looked back.

When given a tradeoff between intuitivity and other benefits, vi almost always breaks against intuitivity. It's this design philosophy taken to its logical extreme.

There's a better fit than "intuitive"

Vim is extremely intuitive in its compositional behavior; I have never used "67w", but I know exactly what it would do because of composition.

I think "discoverability" is closer.

I understand the frustration since even as a veteran users of Vim, there are lots I do not know about.

Vi is a completely different way of thinking. I would compare it to learning to program. When you first start, there isn't very much that is discoverable. You just have to sit through the learning. Once you do, you have access to a lot of power.

I have switched to doing most of my work on IDEs like IntelliJ, VSCode, etc and the first plugin I always install is vim keybindings. It makes editing and navigating much better.

I've always thought that doing 5dd and such was a bad demonstration of Vi(m) since I never know how many lines to delete. I'll just dd multiple times. More powerful vim commands are like daw (delete all of a paragraph), di) (delete inside of a set of parentheses), and dtX (delete until the character X).

daw deletes the word you are in (delete a word). But dap deletes a paragraph. And you can tell vi what you mean by "word" and "paragraph" (I think) in your settings file.

Good catch, I meant dap.

If you use relative line numbers, 5dd makes total sense.

I tried this for a while but it never clicked for me. I prefer using semantically-meaningful groupings like paragraphs or parentheses, it just seems nicer. And relative line numbers wouldn't make, say, 5dw any easier to count.

You can use: df<char> to delete forward (including char), dt<char> to delete forward until char. (excluding char) d/<search><Enter> to delete until search pattern is found

In case you wish to type immediately after deleting, replace 'd' with 'c' in the above.

Also to add to this, dt/pattern_string_here is really handy for deleting until the occurrence of some pattern.

My shorthand when I don’t know the number of lines is dj followed by a bunch of .’s :)

I prefer Vim's visual mode (Shift+V) for that.

But yes, `dap` and friends are options too.

I’d also add https://www.vimgolf.com/ as very powerful way to improve vim skills.

I've been coding for a bit more than two years, then I decided to finally learn vim. I honestly don't know how I did before, it's just so satisfying! It's not even as hard as they say. +1 for vim adventure, definitely great learning ressources!

>> Vi defines a "language" for operating on objects.

And the objects are text-centric (word, sentence, etc). Add on top of that a powerful macro system, and you get a really powerful tool for text manipulation.

"This is especially important if you have to edit a file on a remote server"

This may have been true a decade ago, but editors like Visual studio code now have remote editing abilities over SSH.

I regularly have 50+ files open at a time for editing/compiling and I've never found editors like VI very helpful.

If I need to make a quick edit to a config file, it does the job.

Now imagine that SSH going from a Citrix windows desktop running on a Windows 10 VM on your linux laptop. Every key press reacts in around a second. Welcome to banking "security"!

Now let's say I want to `d5}`, to delete the next 5 paraghraph. In vi(m) I can do this by telling it "hey vim, delete those 5 damn paragraph!"

In fancy VScode I have to say more like... "Hey editor, wait a sec, I'm moving my cursor over there and select a couple lines which happens to be 5 paragrahs, OOOPS, I went a bit too far, now let's go back. YES, now delete them!".

Other examples:

- "increment this number by 5" - "delete this html tag recursively" - "indent the next 20 lines" - "remove all the arguments from this function call" - etc.

Vim has a language, _that_ is the powerful part.

To be fair, thankfully VSCode (and any of the other fancy IDEs) have basic vim-functionality providing plugins.

> Now imagine that SSH going from a Citrix windows desktop running on a Windows 10 VM on your linux laptop. Every key press reacts in around a second. Welcome to banking "security"!

Oh god are you one of my colleagues?

So if you have an incredibly shitty setup, and have no idea how vscode works, then it might be worth it. Got it.

I have a quite good setup, in general.

Unfortunately this is some external requirement I cannot do anything about. Also, as opposed to many people, I actually got to work and know both the IDE-world (including VScode), and the vim world. I have a base for comparison.

Hopefully you "got that" too.

There are also times when the available bandwidth is limited, so just having to use fewer keystrokes to edit a file speeds up the process. I was able to connect to remote linux servers over dial-up and edit files on those servers with vim without issue. Editing and saving over ssh was more of a hassle since it took longer to save the file (and I save pretty often).

vscode remote will actually perform better than vim over laggy ssh because the UI portion is completely local.

So it is with vim.

Anyway, unfortunately given setup won't even be viable with anything running "local", since in the mentioned citrix environment we cannot install anything, so no vscode, no local vim, no nothing...

Something that I always find lacking in these discussions is that the VIM evangelists never mention the way that I use vim: strictly as a keyboard-only editor plugin.

I tried using vim-only setups but there's so much configuring and weird things. Nothing to me has worked as great as my current VSCode + Vim plugin setup. It's the best of both worlds, as I get the quite frankly absurd speed improvements of VIM while also the great user-friendliness and ease of VScode

VSCode is great and has a lot of advantages. I still use vim in a terminal because of tmux. Unfortunately that means I have to give up some of vscode's advantages.

I'd love to hear more about this. What VS Code plugin are you using to accomplish edits over SSH? I checked out Remote Development, but it is actively unable to function with the open-source version of VSCode:

https://github.com/VSCodium/vscodium/issues/240#issuecomment...

> This may have been true a decade ago, but editors like Visual studio code now have remote editing abilities over SSH.

VS Code and vi have different use cases. Contrary to what you said, most people are not going to open VS Code to make a quick edit to a config file. If that works for you, fine, but the overhead of starting electron is significant.

You are right that it is not as necessary as before but there are still plenty of times where vi was still the faster option. Since Vi is so lightweight, opening large files remotely might be useful vs vscode remote ssh.

But yea vscode remote is really good.

What I observe is that most vim fans who swear by it use it as a bare bones editor, syntax highlighting at most. No auto-completion, go to definition or any other IDE stuff. Yes, it is possible to make vim IDE-like but very few do so.

> No auto-completion, go to definition or any other IDE stuff.

vim has had those features for many years now, so I'm not sure why people wouldn't make use of those features unless they aren't aware of them.

Tags! I do wish I knew how to use that feature better...

The existence of "modes" is also opposite to the approach which is know for decades to be less prone to accidental errors: having no modes and always being able to perform more undo steps.

There were even the games of considering what plain text typed in wrong mode would cause the most of the damage.

The main reason Vim and Emacs have their current followers is that the competing editors on Linux or Unix platforms are significantly worse (on average), not that these two are by any means any kind of the possible optimum. And boy, is the competition worse.

(Personally, I use console editors only if I have to, and then prefer to use vim, but otherwise I prefer my customized low-footprint programmable GUI.)

> The existence of "modes" is also opposite to the approach which is know for decades to be less prone to accidental errors: having no modes and always being able to perform more undo steps.

vim has had the multi-level undo and redo for a number of years. If I really screw up, I can always run something like :earlier 5m to get back to the state I was at 5 minutes ago.

The only problem I have with some of the normal mode keystrokes is when I want to use some of the window based shortcuts and accidently press ctrl-w while my browser window is open (which closes the tab) :)

The power that vim has out of the box is pretty incredible. The macro system is very easy to use and powerful.

That said, it is hard to learn all these features and modern GUI IDEs are pretty amazing. You can still use vi in many of these editors.

I used to be like you describe, mostly because language-specific plugins were a dumpsterfire of hidden complexity, that really slowed down your editing experience.

While some plugins are brilliantly-designed, it takes a long time to learn how to configure one language plugin to your tastes, and that learning is generally non-transferable to other language plugins. (vim-go fits this to the T, ime).

https://github.com/dense-analysis/ale (along with the language-server movement in general) changed my perspective. I now do at least the go-to and autocomplete half of IDE things, now.

Have you tried language server implementations like coc.nvim? They seem to be superior to ale and others that don't use the Language Server Protocol.

I know some people at work use it, but I haven’t gotten around to trying it. What’s the advantage over using ale to compose gopls or python-language-server? Is it the fancy windows? :)

I took a cursory look at their repo. I might be understanding this incorrectly, but it looks like you have to run node as a sidecar to use it? Isn’t that really intensive vs ALE? I figure if I wanted to run V8, one might as well use VSC, which after all is an electron app. :)

Yea the dark side of Vim is that it is at best IDE light. With coc, it has gotten better but still far behind vscode.

It is a trade off I gladly accept to use vim and tmux. Aside from that, vim plugin for vscode is pretty good for doing pair programming with the team.

Bind your caps lock to ctrl+left/esc too. It's so much better than reaching for esc/ctrl all the time.

I do use CAPS LOCK from time to time when typing. I find that using ctrl-[ works (left pinky for ctrl and right pinky for [) for me.

Many of those features are Vim features and not Vi correct?

Yes. I believe vim and neovim is what most people use these days.