> I also wonder if Vim is a productivity gain at all.

The big productivity gain for me doesn't come from faster editing due to the shortcuts, per se, but from the golden combo of modal editing and macros. Due to how you treat similar looking text in vim, macros are much more powerful than something like multi-line-cursors, which break down when you want to, for instance, delete the first part of 5 pascalCased variables with different lengths. Luckily, iirc, the vim integration in VSCode supports macros, so people who want to keep working in VSCode because of the excellent ecosystem can still have the best of both worlds.

How would you achieve your example with macros? My inclination would be to do this with regex replace and I can't think how I'd do it with macros. I guess there's some functionality I'm missing? Jump-to-first-upper-case-character?

> delete the first part of 5 pascalCased variables with different lengths

In VSCode there are available bindings for subword navigation (shortcuts starting with cursorWordPart).

There are probably people who are very effective in vscode and the likes. But my patience is tested anytime I'm helping someone or pair programming and I have to watch them navigate the code and make their edits.

In my head all I can think of is all the ways it could be done faster in vim, so it's absolutely a productivity gain, even if it's just a plugin for vscode.

”Some people are inefficient with X“ does not mean X is inefficient. They may just be bad at using X.

While I get what you're trying to say there are benefits to modal editing that learning all the keybindings in X can't replicate. It's difficult to explain and has to be experienced to fully understand.

As a quick example what are the vscode equivalents of I and A to enter insert mode in the beginning or end of a line? These small things quickly add up.

These days if someone using VS Code asks me how they could be faster, I would be much more inclined to give them some tips that work in VS Code than I would be to encourage them to learn Vim or install a Vim extension.

Ctrl-a and Ctrl-e do what you say in VS Code (same amount of keypresses as “I” and “A”, or fewer if you're in insert mode in Vim, and you never need think what mode you're in).

Ctrl-w gives you visual selection of the word under the cursor. Repeat to extend the selection (similar to nvim-treesitter's init_selection and node_incremental, but you don't have to set up treesitter and bind shortcuts or learn how to use visual mode).

I use Neovim and learned to use VS Code without Vim extensions (to help/teach others, and out of professional curiosity!).

Editor “X” absolutely can replicate features from Vim well enough in a lot of cases for the differences not to matter too much, because editor X also does some things better or faster than Vim. Plus we can fill in many gaps that really bother us with extensions. For example, this extension for VS Code lets you switch the cursor from the start to the end of a selection similar to 'o' in visual mode in Vim: https://marketplace.visualstudio.com/items?itemName=rioj7.se....

What _does_ seem to be true is that people who use editor “X” are sometimes less vulnerable to spending their free time learning the features and shortcuts of their editor that would make them just a little bit faster. Vim/Emacs users tend to do that because for us text manipulation and editor hacking are a weird kind of hobby.

But I pair with a lot of senior devs who are _very_ fast with VS Code/IntelliJ these days without Vim extensions. I have also spent much less time making VS Code completely keyboard-driven than I have customising my Neovim config to achieve largely the same abilities (only with Neovim I also lack a lot of healthy things like screenreader support). In VS Code I just needed:

- File Browser (keyboard-driven file nav/creation without using the tree view): https://marketplace.visualstudio.com/items?itemName=bodil.fi...

- Edamagit (keyboard-driven git commits): https://marketplace.visualstudio.com/items?itemName=kahole.m...

- [Optionally]: VSCodeVim ( https://marketplace.visualstudio.com/items?itemName=vscodevi... ) or VSCode Neovim ( https://marketplace.visualstudio.com/items?itemName=asvetlia... ).

Yeah, I did a search and realized it was the emacs bindings but didn't bother editing my comment as most people I've worked with don't know them or even stop to consider if it's possible. A better example would be o/O, c3w, ci) and so on. Even holding Ctrl+[Arrow keys/backspace/delete] to move word by word is rare to see even if supported everywhere.

Of course (and I mentioned it in my first comment) there are people fluent in vscode but it's far from the norm, and doesn't have to be. As you say for vim users it's a hobby or even lifestyle.

But this thread started with questioning if "vim is a productivity gain at all", and I'm confident it is. I use it everywhere from window manager to browsers, and where it isn't natively supported by plugins/extensions I add my own keybindings to get at least movements and scroll.

Funny, several people commenting on this post are making exactly this argument, but at vim's expense.

I'm not sure if it's much of a productivity gain, but the way I have it set up it is really easy to navigate quickly and precisely through buffers, folds, characters, etc. And it always works once I've installed my config files without any further messing around.

To possibly answer your question, think about conveniences that every editor gives you: Editing per (UFT8) character, instead of code points, or bytes or even bits. Would that make you less efficient? I'm sure it would.

Conversely, saying "delete in parens" instead of "move forward 5, delete back 10" is also a real gain.

That being said, use what you have. With editing, and navigating the same file, Vim or it's emulations are almost always better, but most editors offer great cross-file features you should also use, like the "shift shift" in Intellij IDEs, or "ctrl-p" in vscode.