Many advanced tools aren't "user friendly" when you only apply that to how quickly you can understand them. Vim has a steep ramp for usability and power, but the payoff is that it decreases in steepness after a while and (this is important) continues for quite a while. It doesn't do that by slowly doling out the standard set of features over a long period, but by giving you many advanced things you can do which end up greatly increasing productivity.

First you learn how to enter text and move around a bit.

Next you learn some more advanced features to move and edit more effectively.

Then you learn that vim actually functions at different levels, characters, words, lines, and paragraphs, and learn ways to work on those items specifically.

You learn that complex macros are built in and can easily be recorded and applied as needed.

Finally (maybe?) you learn that all this combines into its own little programming language made to work on documents, and you can use this to quickly do amazing things.

But here's the thing, even if you stop only partway into it, you've still learned how to edit files in an editor that will be on every Unix machine you encounter, even if that version may not have all the bells and whistles.

It's an extremely powerful and ubiquitous tool. Even if you don't use it as a primary editor, there are benefits to knowing how to use it with a moderate proficiency, so many people do.

I've watched people do work in vim. They don't work any faster than people using VS Code. Quite the opposite. I see them make more mistakes and lose their place often because they don't have the same quality of tools integrated. By the time they've navigated manually to whatever code symbol they want to edit, I've already gotten my edit done and moved back to the function I came from.

The same people using vim swear by using CLI only tools and by the time they've found the command they want to edit and run in their bash history, I've hit Ctrl+Shift+G, entered my commit message and hit Ctrl+Enter to push. In the time it takes them to switch modes, I've already run the command I wanted to run since many commands are a single hot key and others are on an MRU list.

For editing stuff on a live server, in those rare events when nano isn't available I've always gotten by knowing the bare minimum - how to insert text, write and quit. But I haven't encountered a server lacking nano in years.

Maybe I haven't seen the fastest vim user though. So I looked just now and found [0]. I chose to watch [1] and ~1:24 you can see a demonstration of the guy typing out a command, "Switch" to switch a code symbol from the "true" to "false"... I thought that was hilarious because he typed 6 characters (7 if you include ENTER) in order to save himself from typing 5 characters and I just couldn't watch anymore after that so I left, wondering how many man hours have been spent bike shedding in vim.

That said - I didn't have the patience to find anything showing somebody doing something in vim that can't be done faster in VS Code, Sublime, etc. - so maybe a vim fan can point me in the right direction?

[0] https://old.reddit.com/r/vim/comments/3k1b7n/fastest_vim_vid...

[1] https://www.youtube.com/watch?v=zIOOLZJb87U

I think you didn't quite understand what you were seeing in that video. That's a person showing off a quick plugin/function they made for vim that when called can switch things defined from one state to the opposite state. The top half of their screen is the source to what they wrote (I think, on mobile).

They are showing how it works, so as an example highlight/select manually a bit of text then manually run it to show it swapping the value. There's a few things to consider here:

- They are typing it out because the are demoing it and that's the name it's defined as in the code. Normally someone adding it would also add a key combo activation for it if they planned on using it often in that manner, and make it work on the word element under the cursor.

- Even if a key combo wasn't added, they could also use this while selecting a larger chunk of text to switch all occurrences of one thing the the opposite.

- The real usefulness for this is more likely in the case of some well formatted JSON, where you could start a macros, search for the next top level object, they search for a specific key in that object you know is the next occurr nice of a search term, then go to nth item, then run switch (maybe even typing it out). Then stop the macro. You can then rerun that macro with 1 (or at most a few) key presses the number of times you want, to perform those complex actions a defined number of times.

As needed, vim is like an extensible interactive sed command. That doesn't mean I never use vim, but being able to do something similar to the text manipulations I do with sed while withing the file to confirm it worked right and undo if needed is sometimes useful.

Could the JSON example above have been done with a dedicated tool? Sure. But it gets more complex for dedicated tools if the JSON is embedded in something else, and the important idea is not JSON editing, but that vim gives you a toolset that works just as well for XML or source or plain text, as the primitives it works with generally map well to how we use text.

Thanks for the explanation! I'll try to watch a few more videos.

> learned how to edit files in an editor that will be on every Unix machine you encounter

And this is instant cred when one is new to a project, and have to log in and fix something on a random serber out in the cloud.

Vi is something of a litmus test.

Vim is very user friendly - to power users.

Yes, it takes a bit to get used to its controls, but I'm not sure there's a super easy way to teach modal editing to newcomers. On the other hand it's a really reliable and efficient tool that just doesn't try weird stuff. If you have a 1000 line configuration file you can blindly upgrade to the next version and trust everything is still working exactly the same. Considering how many apps do the opposite and add random changes all the time to A/B test everything, this is very valuable.

And while I wouldn't call it perfect, I think editing text is really, really intuitive and fast once you're used to it, to a degree using a mouse in other editors feels slow.

I don't think it's the "pure" opposite. Notably, it's extremely stable and even all of the quirks which aren't fixed for reasons of compatibility are documented in its built-in help.

I think almost all modern products focus exclusively on growth: acquiring new users. That means that it's OK to break existing behaviors if it makes something easier for a newcomer. Vim does not have this attitude, so a newcomer has a steep learning curve, but an old-timer doesn't have to worry about his platform changing from under him.

Thirty-five years ago, I had a couple of slightly frustrating weeks sitting in front of a VT-200 serial terminal.

Over the subsequent three and a half decades, I've had an editor on virtually every computer system worthy of the name which Just Does What I Want It To. It's there for everything from one-liners to book-length files to editing multi-GB datasets or Web scrapings.

And I'm still learning features and concepts, though now around vim rather than the original BSD vi.

And no, vi isn't the only editor I've used with proficiency: DOS EDIT, EDLIN, KEDIT, WordPerfect 4.11, VMS EDT, VMS EVE, TSO/ISPF, Emacs, pico, nano, and more.

I quite honestly wish I could get back into emacs, but vim has a stronger pull and solves virtually all my problems. org-mode does have strong appeal, however.

Love org-mode. You should look into Spacemacs or Doom Emacs, with their focus on vim-style keybindings. I’m still learning my way around Emacs so appreciate Spacemacs for its discoverability. Doom is supposed to be quicker and more stable though, so it sounds like that might be the distro for you.

I started using vim quite recently and I have a pure opposite view point as yours. With vim, I find myself editing code effortlessly, without conscious effort. This never happened when I was doing this with other text editors using keyboard shortcuts or the mouse.

How did you get started?

I was using vim mostly while working on projects with a single board computer. But at that time I only knew the basics of searching, jumping to a line and entering insert mode to edit some text.

Recently I installed vim plugin for vscode and spent a little time digging deeper into vim and practiced until it got into muscle memory.

One little shortcut that I've noticed even some experienced users aren't aware of is :x to save and exit. It is equivalent to :wq

It's the opposite of new-user friendly design.

For some of us, it isn't that hard to learn, and gives us an entirely new way to think and interact with a computer.

I think there is a powerful lesson for user-facing application developers here. Sometimes you're better off thinking of power users and enticing newcomers to put in the effort. Blender seems to follow that approach as well.

A violin is the pure opposite of user-friendly design, and yet, there are millions of people playing it.

Yes, but only a violin can make the violin sound.

I'm a vim user sometimes because of the peer pressure but it's basically a cult and a waste of time if you can avoid it.

The reason vim doesn't use cursor keys for movement is not because of some secret insight but because the keyboard it was invented on didn't have them.

Similarly the concept of modes was just due to the time period. Commands were the normal way to operate editors. For many people, not many years had gone by since the editing was done on a teletype. Interactive editing was barely even a thing.

I recommend the `micro` editor.

The historical reason why home row keys are used for movement instead of cursor keys is irrelevant. Even if the idea was a historical accident, it turned out to be a good idea. Not having to move the position of your hand to move the cursor is comfortable and fast.

The basic vi assumption is: "We spend more time editing text than authoring it, and therefore the keyboard itself is the UX."

This is loke starting a maze at the end, amd precisely the sort of backward thinking that affords some excellent solutions.

This isn't to scoff at great UX and design work; merely to point out that the wildly offbeat can surprise in a good way.

The beauty of Vim is that it uses almost a natural-language approach to editing. It's not the opposite of user friendly, it is, in fact, much closer to the user's consciousness, than many other editing paradigms. I.e. when I am editing text in vim I am translating my intentions to vim commands almost directly. "Change this paragraph" becomes "cip", or "cap" as in change inside/around paragraph. Select text up (or down) to line 30 is v30G. This one does not translate to proper English directly, but it's pretty straitforward when you know how to build Vim's "phrases".

The way I finally got vim to stick was by integrating it into my existing development workflow.

I had tried to go all in on vim a few times but the learning curve always made me feel less productive than working in VS Code.

After adding the vim extension in VS code and gradually learning new commands, it stuck.

Very happy to have learned vim but I agree that the learning curve is pretty steep usually. It was frustrating enough that I published an interactive vim course that helps people get over the hurdle.

ergonomics, intuitivness, functionality are the three sides of software development.

If you favor one corner, the opposit side will degrade.

VIM is full on functionality/ergonomics with absolutely zero intruitivness.

It's a very steep learning curve.

Once you reach that point in the curve where stuff are easier/faster to do in vim then something else, you can never go back.

ergo the user base.

Vim is like an F-15 fighter jet. You have to study and train to know how to use it, and some elements of its design are historical or just bizarre, but if you know how to use it you are far more capable than you would be with other tools in the same category.

Sounds like you're using it wrong. I love that I don't have to touch my mouse and can do everything a that an IDE can do.

Also very importantly, it doesn't report everything you do under the telemetry umbrella like all Microsoft products do.

Or cripple projects that remove that telemetry (see Vscodium which cannot use remote extensions and the new default LSP named Pylance, because Microsoft forbids it).

Edit: vscode also has some proprietary debuggers.

https://github.com/VSCodium/vscodium/blob/master/DOCS.md#pro...