Visual Studio Code team considers Vim mode depending on upvotes | Hacker News Reader

Visual Studio Code team considers Vim mode depending on upvotes

github.com

56 pointsdschuessler27 comments

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.

insert Office Space NOOOOOOOO gif

Sorry but please stop. No one needs yet more bloat in Vscode, and its trying to be all things to everyone. There are already extensions for this.

Whats next, eMacs mode, Jetbrains mode?

I agree - I already use an extension for emacs key bindings that mostly works.

With such a rich extension ecosystem I'd rather see them invest in enabling extensions to do this, rather than adding the functionality themselves.

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.

"When we refer to 'up-voting' a feature request, we specifically mean adding a GitHub +1 reaction to the issue description."

I have no horse in this race, but ~45% of upvotes seems to go to triage-bot's comment linked from this thread.

I wish VSCode would stop bloating to accommodate every little request under the sun. I thought that's what extensions were for.

VSCode core should be very lean and mean, instead I feel like every version of VSCode gets bigger and bigger.

There is a Vim extension but changing VSCode to act like Vim is really more than you can do in an extension, especially performantly.

VSCode extensions don't have free reign to modify anything they like.

What do you think is missing and not fixable in the extension? We've even got the neovim extension which literally runs vim in the backend.

I thought that's what extensions were for.

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?

Honest question, why not just literally use vim if you love vim workflow? Why do vim users force vim support on every other text editor?

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.

let's not forget how big vscode is, 260mb

to have an interface where you type text

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.

wow it only takes 20 upvotes? #easywin!!

Only 20 because that just gets it to the backlog

With a bar this low, that backlog must be a nightmare.

Does Microsoft actually implement all backlog items, or is it just a queue of issues for them to look at?

I don't use vscode but I just upvoted. Hope it's speed/UX can be made comparable to vim.

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.

You're never too old. It's just the new tools are not good enough.

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.

Disclosing the conditions doesn't seem fortunate on their side.

Reply on news.ycombinator.com