The vscode vim bindings are atrocious. I use them because there's nothing better, but they're bad. Slow, super buggy, and did I mention slow? I hit tab and sometimes instead of inserting a \t, it inserts the letters "<tab>". And it re-runs mypy/flake8/etc whenever I enter or exit insert mode, which I do a ton... so my CPU is constantly pegged. And commands like "2d}" don't delete the correct amount of paragraphs. And one more I forgot: The undo stacks aren't synced between vscode and vscode-vim, so vscode's undo can undo an undo. <sighs>

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.

What's the bug that you have with `2d}`? It seems to work fine for me.

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.

> Overall, I do agree that there's stuff that can improved, but it kinda hurts to see people call them "atrocious"

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 :)

Just want to say thank you for what you do. Contrary to this users experience I find the Vim bindings in VSCode to be probably the best I've ever used in any IDE. Keep up the good work.

I use VSCodeVim every day and I just wanted to say thanks for your work. You made the switch to VSCode a lot easier for a lot of people.

I don't think the undo feature is built out well enough for it to be a great idea for you to switch to it. I tried to build an undo tree and saw that there is a granularity mismatch between the internal stack and yours. I think the API should be redesigned so that plugins can manage the undo stack but the team seems pressed on time so I gave up for the time being. The issue is still open so I'm hopeful they might come back to it.

I'm sure the real Vim power-users might miss a whole bunch of stuff, but I consider myself an intermediate Vim user, and I think VSCodeVim is great. Almost all Vim commands I use seem to be supported. So thanks for your work :).

I really appreciate your efforts in improving the Vim experience on VSCode, but the extension is slow enough that I find it unusable. I desperately check every changelog update to see if the performance issues have been mitigated, to no avail.

Thanks for your work. I've been using vscodevim for a while and it works like a charm out of the box.

The author of vscodevim is working on a new extension that uses NeoVim's remote UI client protocol. Accuracy and speed will hopefully go way up when that is finished. Unfortunately progress appears to have stalled somewhat.

https://github.com/Chillee/VSCodeNeovim

I went back to "vanilla" NeoVim solely due to the slowness of the VSCode Vim plugin. Been watching the repo you linked a couple of times a month and always disheartened that nothing seems to happen.

Which extension do you use? I don’t use vim mode myself but I vaguely remember seeing a conversation about how, for some reason, the better vim plugin with the most favorites doesn’t appear on the top of the search results, and an inferior one is there instead.

I've tried just about every single one and the best one is still the main one. It gets better just about every release similar to VSCode. Not saying it's perfect, but with all of the other VSCode benefits I find it so much better for productivity than plain Vim.

This one: https://marketplace.visualstudio.com/items?itemName=vscodevi...

I had similar problems. Certain key combinations in vscode would cause the cursor to delete or corrupt large sections of my code and delete the undo history. After losing hours of work a few times, I went back to Vim. I really like the process of customizing my editors and having them work the same on all machines, even remote servers. (Vim for coding, and Emacs/Evil for Org Mode.)

i agree with these observations

There is an upvote button so you can convey that appropriately :)

> can benefit one a lot.

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.

> 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.

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.

I'd rather say it's the unix way. Check out this[1] screenshot. tmux, and inside is vim, git, and cargo visible. My work environment is based on simple primitives that are all able to be composed and set up to ones preferences.

[1]: https://imgur.com/a/A9b3izE

I mean, it sounds like to me vscode has nothing to offer you, if your desktop (i.e. what we see when we look at your monitor) remains so static (in a positive sense).

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 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'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.

[1]: https://imgur.com/a/A9b3izE

> 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.

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.

Yup, this is also my setup and workflow, and I also agree with what you say about VSCode feeling 'confining'.

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.

Could you expand on what "Your way" is? I really really like VSCode for Python and never had the nerve to learn VIM, so I'm wondering what you do that causes it to be a fight.

Well, the setup I mostly use looks like this: https://imgur.com/a/A9b3izE

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.

This is pretty much why I haven't moved fully to VSCode as well. I gave it a try but I realized that my whole workspace is in terminal. Also, like you said the tools I have compliment to one another very well making it very flexible. The only thing I do miss when working in terminal is that whenever I'm working in markdown I wish it had dead simple preview like that in VSCode.

I do all my document-making in emacs with org-mode and evil (vim-mode). Seriously, it's amazing. When you are done, you are one command away from having it in markdown/pdf/latex/html/word or any other format you can imagine.

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.

Okay you convinced me with that org-mode. I've already invested huge time learning vim and hopefully it translates well in evil.

Edit: Ah, I see emacs has it's own terminal which is why it was able to support charts and graphs.

I could never get used to NERDTree for navigating through my project. What plugin do you use for project navigation?

I use fzf[1] for all my project navigation needs. It integrates very well with vim. You can get a quick recursive look at everything in the CWD with a stroke of a key and the fuzzy matching is instantaneous.

[1] https://github.com/junegunn/fzf

not op, but i use ctrlp.vim for everything. feels a lot better than most things.

Yeah, exactly. I use NERDTree for discovering new projects, but other than that, I use a fuzzy matcher for files and buffers. I used ctrlp for years, but recently switched to fzf because it's just faster.

Fzf and ripgrep <3

I would really love to ditch more of my nvim setup for vscode, but this bug [1] from 3 months ago absolutely wrecks my productivity. I rely on splits as the primary means to navigate the codebase and having a single cursor position per file is maddening!

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

Ooohhh, this is something that I've been meaning to get back to...

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.

Yeah VSCode for Vim feels like they are slowly trying to implement a subset for VSCode. This kind of iterative approach doesn't strike me as a way to build something that will finally "feel right", and overcome these limitations. Perhaps some remote vim running actual nvim code with a minimal API bridge into VSCode is more appropriate?

The maintainer of vscodevim has done a lot of work on a plugin that uses such a bridge. :-)

sounds like https://www.onivim.io/ to me