I've reported all these bugs with not much in terms of answers. I've even tried contributing but it's a pretty messy codebase to get into. Ergh.
There shouldn't be any reason that it reruns save upon entering/exiting insert mode; are you sure you don't have some kind of keybinding/other setting that's autosaving for you?
The `<tab>` issue is kind of a pesky race condition that's most likely exacerbated by VSCodeVim running slowly on your computer.
Speaking of it running slowly, I would argue against characterizing them as "slow". Some small subset of users seems to have consistently run into this issue, and a decently large subset of those users have realized that the issue is caused by some conflicting plugin, so I'd suggest trying that too.
As for the undo issue, I have mixed feelings about it. Perhaps it could be synced with VSCode, but it's definitely true that when it was first implemented, VSCode did not provide the flexibility to do so.
Overall, I do agree that there's stuff that can improved, but it kinda hurts to see people call them "atrocious". I suspect your main issue with VSCodeVim is really the "slowness" issue. I would try disabling other plugins and see whether it helps.
EDIT: Forgot to mention. Disclaimer: I'm one of the primary maintainers for VSCodeVim.
Sorry :( I hate to be harsh and I don't want this to get you down, because I have a lot of admiration for the work you do (and this goes to any open source work I've ever criticized, really). So, thank you for your work.
But... the usability is really bad. They would be completely fine in a vacuum if vim didn't exist, but the point of comparison exists and it's vim and vim is just crazy fast compared to vscode-vim, it's like comparing a racer... to a fighter jet.
> What's the bug that you have with `2d}`?
That only deletes one paragraph (like 1d}) instead of two. 3d} only deletes two, and so on. It's not consistent with vim.
> There shouldn't be any reason that it reruns save upon entering/exiting insert mode
shrug, I filed an issue about this a couple weeks ago after a decent bit of debugging.
> I suspect your main issue with VSCodeVim is really the "slowness" issue
ish, it's definitely the primary pain point but there's also lots of small bugs and inconsistencies with vim. And I understand that competing with vim itself is hard, but the other comparison point is for example pycharm's vim plugin and vscode's is far behind.
Edit: And just to echo tdfx's point, without your bindings I wouldn't even be on vscode, so there's that :)
What are those benefits?
I tried to switch from vim to VSCode, and it just felt like it confined me. To be fair, I don't "run vim", per say, I run a shell with tmux inside, split horizontally in two, with vim on top, and two shells (a vertical split) underneath. The left shell on the bottom being used for miscellaneous things, and the right one running some kind of live code checking (with visual results also inside vim).
This setup works great for both c, c++, python, haskell, rust, node and any other programming environment I use. I tried getting something along the lines with VSCode, but it confined me, and it felt like it wanted me to do things "its way", instead of letting me decide what I have found out works through years of experimentation. It's the same with jet brains and xcode and visual studie... It doesn't let me do things "my way" but instead forces me to do things its way, which, if I may say, is highly inferior. I have tried their ways and it's not good.
Sorry for the rant.
I've tried getting something like that going in VSCode, but even just switching between terminals and compiling and so on is just too confining. Whenever I've tried, there's always some part of it that doesn't let me easily do something, because it expects one to use it some other way.
With a shell, tmux, vim and other CLI tools, it's all based on basic primitives that all function the same way and you can compose them as you like. It just works. You can't do that with VSCode or any other IDE. They all put limitations on you and if your preference doesn't fit its, you're out of luck.
I'd love if I could have the same power for managing my todos, tasks, projects, taking notes, README writing, overall agenda with vim, but I can't, so I find it's easily worth it just to use emacs and org.
Here is an example of what you are able to do with emacs and org: https://imgur.com/a/3rTNVYE
And if you need it in markdown, you just manually export it, or set up a hook that does it for you every time the document changes.
And no, the result of the code-blocks in the screenshot is not something I manually inserted into the notes. Org runs the code and inserts the result for me automatically.
Edit: Ah, I see emacs has it's own terminal which is why it was able to support charts and graphs.
I find vscode more useful than vim because I can quickly and easily swap out the pieces of environment I need. Need a terminal real quick? Ctrl`, command, ctrl` again and poof it's gone, with nothing in front of me but my code. Need git real quick? Ctrl shift g. Need one more tab? Another? Ctrl \, and so on.
I usually work with three or for different files opened, some tucked away in a tab that I can quickly shift to when I need it. And when I need to get to my "wall o' terminals", I just switch to that workspace (gnome).
Whenever I watch the local vim lady do her thing, it's an entirely different workflow. Grepping across files, then opening one in vim so it just kinda pops up in a new terminal window. Doing a thing there, then closing it to go work in a different vim window... Admirable memory map of the code base and confidence to just close the file and move on, but not for me.
I'm able to do all of these things too with my setup, although it's not vim driving my setup, it's tmux. Using just plain vim doesn't work for me.
> I usually work with three or for different files opened, some tucked away in a tab that I can quickly shift to when I need it. And when I need to get to my "wall o' terminals", I just switch to that workspace (gnome).
Most of the time, I have two files open too, sometimes three. I never use tabs for files though. If I need to work on multiple files, I have them all open in splits. Seems to work fine all the time. I use ctrlp to easily switch between buffers and files.
> Whenever I watch the local vim lady do her thing, it's an entirely different workflow. Grepping across files, then opening one in vim so it just kinda pops up in a new terminal window. Doing a thing there, then closing it to go work in a different vim window... Admirable memory map of the code base and confidence to just close the file and move on, but not for me.
Yeah, doesn't work for me either... My setup looks like this[1] most of the time, and I'm easily to add any and everything as I need it.
For a while I was running (g)vim8 with the built in :terminal - but I had some character issues with meta mapping (so typing tings like ~ on my Norwegian keyboard layout was a chore). Qt neovim didn't have these issues, whatever caused them - but I also switched back to a tiling wm (i3) - and I'm not sure if screen in neovim term really is better than a neovim on one side and a terminal w tabs on the other.
What I will say is that vim8 has a "better" terminal out of the box than neovim (that realized the idea first) ;in vim switching out of insert mode is easy and allows real nice copy to buffer - say to copy from a repl, and switch windows to paste into a file.
The limit of one (two) x11 clipboards is a bit of a pain, but with setting the x clipboard to default copy/pasting between vim and the rest of the world becomes pretty painless.
Anyway - point being, vim/neovim has great support for managing terminals - but I'm not convinced it's a great idea.
Arguably that's not "your way" either but "vim's way", which you've adopted over those years of experimentation by force. Only now that there are alternative options which are equally as powerful is it apparent that there are other ways of doing those things.
This is probably just a matter of opinion/preference, but I feel like an editor should simply be an editor -and IMO there is no better editor for turning thoughts into code with minimal friction than VIM/Neovim. The OS functions perfectly fine as an IDE for everything else.
The vim bindings aren't perfect and are sometimes slow (you can see a macro insert things character by character) but about on-par with IdeaVim for the IntelliJ side feature wise.
Maybe oni [2] will catch up before vscode fixes their issues but I eagerly await a decent language server modal editing setup.
[1] https://github.com/VSCodeVim/Vim/issues/2688 [2] https://github.com/onivim/oni
There was an atrociously bad "undoing work" issue that I popped out of hiatus to fix, and that bug was the cost of the fix. I meant to add proper support for that, but me not using splits that much (especially for the same file) as well as other commitments have prevented that.