Clarifying what "vim mode" means would probably be helpful. Sublime's "vim mode" is more like vim bindings, and a proper vim ex mode requires a separate extension in Sublime, IIRC.
But for some people, vim bindings might be enough. I know I frequently miss them when I'm working within Notepad++.
Agreed. I think existing plugins handle vim plugin compat, but for those of us who just miss modal editing it'd be nice to have support for that via existing keybindings.
The existing key chord feature in VSCode made up for a lot here, but being able to switch modes for when I'm editing vs reviewing would be pretty neat--especially if I could change key bindings for each mode.
At least for my workflow, I haven't run into many issues with the current VIM bindings for vscode. I agree with the commenter who says it would be helpful to understand what's missing from those.
That’s the fate of most ‘code editors’. They start as a lightweight replacement for heavy IDE’s, but becoming more popular, getting more and more features just to end up as heavy as IDE’s, but with less features still.
For my use cases, the existing vscodevim extension has been pretty fine.
Macros would be nice but my keyboard supports on the fly macros so it’s not a show stopper.
I wouldn’t mind an implementation of :move but the nice thing about vim is it’s easy enough to work around that being missing in vscode vim.
Essentials like :%s///g work fine, regular motions are fine too in my experience.
The clipboard, now that i think about it, that isn’t a great story, even with use system clipboard enabled i’ve had a few p or ctrl-r * ... huh? Moments.
Sometimes the core application has to change to expose things those plugins need, and without considering the use cases of what people want it's very hard to know where to focus engineering effort that will make a difference for both users and plugin authors. Adding a Vim mode could lead to other interesting plugins, user benefits, and a better experience for everyone. That's why the VS Code team are asking the community to vote on this issue.
> Sometimes the core application has to change to expose things those plugins need
Sure, I'm all for that. I want the extension api to be flexible enough to fully accommodate this type of stuff. I don't want sublime vim bindings as a core feature bundled in with every copy of VSCode, it's not something will ever use.
Cursor movement is latency sensitive in a way that 95% of plugins are not. An editor where your cursor doesn't move when it's supposed to is very distracting -- I think for most people, it's disqualifying. I like VSCode, but my primary machine is a 2015 MBP and I can't use VSCode as my primary editor because the vim lag is too strong.
It's not simple to engineer a plugin system that can accomodate this. There aren't that many preferred input schemes, why not just support them as first-class?
He (like me) probably uses BOTH vscode and vim. VSCode has a number of great extensions I love. VIM has a number of great plugins I love. I love both editors! Now, I just need VIM input scheme on both, for fast, consistent keyboarding that leverages my muscle memory.
Except that’s not all it does. Surely you don’t reduce a web browser down to “an interface that shows bold text” or a television to “a box in my house that shows me Ben Stiller”.
So let’s call it what it is: an IDE. Compared to other IDEs, vscode is the smallest. IntelliJ is 750mb. Xcode is several GB now. Visual Studio can be like 100GB with all the options included.
Sure, if you’re comparing vscode with a minimal vim install, it’s huge, but not everyone can use a minimal vim install to get things done effectively.
Seems impossible to me that an electron app can respond as quickly as native code one.
Ignoring other issues I had, I ditched VSCode and went back to MacVim after probably 3-4 months specifically because of the input lag I experienced when typing. The input lag seemed to be tied to things like plugins looking up information like autocomplete, which, I know is more computationally expensive than simple text rendering but it seemed like VSCode blocked simple text rendering on waiting for autocompletion results.
I did have a number of other issues, but, I enjoyed VSCode enough that I would have stuck with it and tried to resolve. Now, I'm probably too old and too disconnected from code to actually switch.
Please don't just jump on the bandwagon. There are existing extensions providing extensive vim mode - if you're not using VS you don't know what's already possible.
But for some people, vim bindings might be enough. I know I frequently miss them when I'm working within Notepad++.