(even though it's not 'real vim', it's good enough for using both cmdline vim and vscode without the brain having to switch in and out of 'vim mode')
there are almost always quirks, but the biggest issue tends to be when bridging the gap between vim and the GUI itself, particularly around the modality of vim vs graphical autocomplete.
If you're less experienced as a vim user these emulators are probably perfectly fine, but as someone who has been using vim for something like 20+ years, they _always_ feel just off enough that I either just go back to vim or edit the way the editor originally intended.
Combine that with the fact that all the UI elements are not vim-ified. In vim, since everything is a pane and a buffer, you just think "I want to select the panel to the left". Regardless of if it's a plugin view or a file or whatever.
In vim emulator's, that's never the case. It's really not the same, but better than nothing. The vscode plugin and the IntelliJ one are both pretty good compared to previous ones that I tried. But the IDEs are just incompatible with the vim ideology, in my opinion.
If nothing else, the performance characteristics of vim are predictable (to me, after all these years) and there are various ways to work around any problems that occur (disabling plug-ins, etc).
Just a little counterpoint basically - I don’t think you need Vim’s entire editor model to get a lot of value out of it!
My comment wasn't meant to dissuade anyone from trying the vim plugins. I was just trying to explain why someone would consider the vim emulation plugins not as good as the real thing.
Not once in the past eight years have I had to use tabs for something. The buffer list, yes. The argument list, yes. Tabs, no.
If all you care about is buffers, what do you miss about them in vscode or IntelliJ? Their idea of buffers is the same as vim, as far as I can tell.
Or is the problem that the IDE functionality is not implemented as buffers? So you can't use your normal keys in non-text places? That was what I was referring in the second part of the comment.
[0] https://github.com/helix-editor/helix/issues/2295#issuecomme...
The workflow he is describing works with :bufdo, :argdo, :bn, :n, etc.
He is also not describing what is special about tabs. Tabs in vim are groups of windows.
I’m not sure if you were asking me, but no, buffers are not the reason why I exclusively use vim.
> The workflow he is describing works with :bufdo, :argdo, :bn, :n, etc.
It's different because you are losing context. It's not about finding the right buffer, I understand buffers, I have no problem switching between them and finding them. It's about organizing windows in a way that makes sense and then quickly switching between them.
> He is also not describing what is special about tabs. Tabs in vim are groups of windows.
Exactly! And no other editor implements it that way. It's about context switching quickly. I setup my tabs per context and then I can quickly switch back and forth between them, and have all my windows like I left them.
No other editor does it like that (maybe emacs?), because it does not have the concept of vim tabs. Other editors use "tab" to mean "vim window". I'm constantly wasting time recreating window layouts in other editors depending on what I'm working on.
> I’m not sure if you were asking me, but no, buffers are not the reason why I exclusively use vim.
I'm asking what is missing from the IntelliJ vim plugin when it comes to buffers. The concept of buffers is not unique, most modern IDEs implement them the same way. It's why I'm surprised that you mention that buffers are the killer feature of vim, since I don't see anything unique about them compared to other editors.
I'm sorry, I think we have our wires crossed :)
I didn't say that buffers are the killer feature of vim — quite the opposite.
I was replying to the opening sentence of your comment, in which you said:
> The problem with every fake vim plugin is that the underlying editor does not implement tabs the way vim does.
My argument is that problems with vim-like plugins in IDEs like VSC run deeper than just the one you pointed out, especially given — in my opinion — neither tabs nor buffers nor windows are the killer feature of vim. But I can see how my comment can be misinterpreted given I said "vim is all about buffers", which in hindsight I think I worded poorly.
If you really want to ease into it then simply enable the (neo) vim plugin in vscode, it's pretty good. You'll miss some big features but you'll have all the bread and butter features. Only risk is that you'll get used to some vscode features as well.
If you're serious about it, you should use it for everything and use it a lot.
The right setting for me is Vim within an IDE (nowadays VSCode) but I've found it too complicated to try to turn it into an IDE. I find it appealing to be able to do all your work within tmux/vim, and I know a lot of great coders work that way but it's been too much hassle for me.
I also wonder if Vim is a productivity gain at all. I like to be able to navigate/edit a file without taking off my hands from the home row, and also quickly edit a file when I'm in the terminal. But not sure it really makes that much of a difference when you know your VSCode/MacOS shortcuts, and I suppose that with proper configuration, you can also edit file remotely with VSCode and restrict the need for edition within a terminal.
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.
In VSCode there are available bindings for subword navigation (shortcuts starting with cursorWordPart).
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.
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.
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... ).
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.
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.
If you keep at it you will develop the muscle memory. I am not an expert in Vim, but I use it whenever I want to write some code. Once I was given a coding problem to solve. The interviewer gave his laptop to me with part of the program implement and I had to complete the program. The problem was the C++ code was written in Visual Studio on Windows and I had not used that setup for a long time. So it was frustrating for me and amusing to the interviewer to see when I use to press Vim keystrokes while writing the code in VS :)
And this is why I have never been comfortable with vim or the idea learning it on that level. Why would I spend time muscle memorizing a program that conflicts so much against all other editing software and related paradigms? The skills do not scale enough to make it worth the effort imo. Sure your vim powers skyrocket but any other interface where you have to type becomes a nightmare to work with effectively.
Are the advantages of working really really well with one tool worth the effort when you lose productivity in every other tool (99.9% of them) out there? Maybe if you can live constantly in vim but how many of us truly only edit text files during our day to day?
Many other programs loosely follow vim bindings. For example if you enable hotkeys in GMail webclient you can use j and k keys to move between emails, press / to search just like in vim.
In the comment you replied to the author was in an interview situation so they didn't have time to install any plugins.
Because no other editor is oriented to muscle-memorizing.
> any other interface where you have to type becomes a nightmare to work with effectively.
Something tells me that you are talking about some interfaces with mouse. It's really a nightmare for mine inner vimmer to get my hands out of keyboard in any other editing interface or even to look at keyboard for searching those Alt-Ctrl-Shift chords.
Then one day I realised I was still more productive in sublime with its simple but powerful keybindings than I was in vim. I dropped it and never looked back.