Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: