VIM mode like sublime

[miked508]

Issue Type: Feature Request

Please add a VIM mode like sublime! I've tried many extentions and they don't behave like what im used to with sublime.

VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:34:46.910Z) OS version: Windows_NT x64 10.0.19041

[astier]

I vote against it. Your only argument is that it doesn't behave like in sublime without even explaining what it means. I personally don't want a vim mode which behaves like in sublime. I want a vim-mode which behaves like vim. For this there are already two great extensions.

• https://github.com/VSCodeVim/Vim

which even implements many plugins. There is also

• https://github.com/asvetliakov/vscode-neovim

which can't get closer to an authentic vim-mode because its using actual neovim under the hood.

Why not trying to make this two extensions better if you don't like something. The ground work is already done there. If you want a better vim-experience in vscode its much easier to implement it in this extensions then to implement a completely new vim-mode inside vscode.

Also who says that the build-in vim-mode would be better then those two extensions and that it would fulfill your sublime-requirements.

IMHO the issues which you currently have with this two extensions (which you never explained) should be addressed in this two extensions instead of wasting the devs time and trying to reinvent the wheel again.

If a vim-mode should ever be implemented in vscode there should be better very good reasons because its going to take a lot of time and resources from the devs.

[domenukk]

@astier have you used the plug-ins yourself? Are you sure the existing shortcomings can be fixed without any help from the underlying platform?

[damien]

I agree with @astier in that this is a poorly defined request and that the referenced plugins look promising. It may be worth instead discussing about support for modal editing within VSCode; or extending the existing keybinding features to better support modal editing workflows. Both plugins need to emulate vim to get the modal editing experience, which seems like it's less than ideal.

[RPGillespie6]

@domenukk Even if that's the case, then VSCode should instead focus on fixing the shortcomings of extensions instead of bloating the core platform with features only a tiny % of the userbase will use. The whole point of extensions is to accommodate niche use cases and workflows. I'd rather have a lean and mean VSCode that I can extend as necessary than a monolithic one that has tons of features I'll never use.

[astier]

@domenukk I used both of them. Currently I am using vscode-neovim. And while they surely are not perfect I don't see how it would help to implement them in core-vscode. The first goto-solution as I already said should be to try to fix the extensions. Only if this is not possible it should be considered to implement it in vscode.

Even if there are features which currently can not be implemented in extensions because of some shortcomings in vscode then first thing we should discuss is if this shortcomings in vscode can be fixed such that the extensions can implement the features which are needed.

So far nobody who voted for this issue gave any reason why a vim-mode should be implemented in vscode and why the issues/features cant be fixed/implemented in the extensions.

[jgowdy]

If the vim mode being suggested here was based on the behavior of vim rather than the behavior of Sublime's vim mode, I think this feature request would make a lot more sense. Perhaps re-wording the feature request would be rational.

If there are flaws in the existing vim mode extensions that can't be resolved without help from the platform, those should probably be their own feature requests as an alternative to this one.

[dschuessler]

To give some context on why the existing vim extensions are perceived as lacking by many, there are performance issues that are (as far as I understand it) due to vim extensions having to share the extension host with all other extensions. Here is the related issue:

https://github.com/microsoft/vscode/issues/75627

The corresponding VSCodeVim issue is in the top 5 most upvoted issues of that extension:

https://github.com/VSCodeVim/Vim/issues/2021

While a native vim mode might not be the solution, the number of upvotes here hints that there is a real and widely perceived problem with the current state of modal editing in VSCode.

[astier]

@dschuessler This is a good start. Fixing #75627 would go a long way and maybe even benefit other extensions too.

[dschuessler]

Since the original feature request is not very descriptive but the issue is getting a lot of attention, I will summarize some problems I observe with the two existing Vim extensions and to what extent I understand these problems to be problems of VSCode rather than of particular extensions.

TL;DR: Vim extensions are sluggish because the architecture of VSCode's extension host allows them to be interrupted by other extensions at any time. This possibly also explains some of the unreliable behavior of Vim extensions.

On the shortcomings of Vim extensions: Editing operations with Vim extensions are slow. On high workloads, I have witnessed typing lag up to two seconds. Also, I find them to be pretty unreliable. They often show surprising behavior that is hard to reproduce, mostly unsolicited edits and cursor movements.

On the role of VSCode concerning performance issues: @DanTup pointed out that the type command used by Vim extensions can be interrupted by other extensions. Extensions using this command are therefore vulnerable to performance issues in principle. Their performance will never be sufficient to guarantee a smooth operation because every other extension can slow them to a crawl at any time. This does not only concern Vim extensions but also the rust-analyzer extension for example. These problems are not hypothetical but a constant issue. Developers of Vim extensions acknowledge that the architecture of the extension host is at least partially responsible for this. (See this, this and this) According to @alexdima the VSCode team recognizes the problem but considers it too costly to fix at this time.

On the role of VSCode concerning reliability issues: @alexdima wrote here (emphasis mine):

By default the type command is implemented by us on the renderer. The Vim extension effectively overwrites it and at some later point (async from the point of view of the renderer) issues edits back to the renderer process. We have no idea that those edits have as root cause a certain keypress or that a long time has passed...

My understanding is this: When the renderer is not capable to determine the source of an edit, it follows that it is not capable to distinguish between edits of different extensions. It follows further that the renderer can not and does not put edits in a specific order. Since other extensions also issue edits (e.g. Prettier, Markdown All in One) this might explain unreliable behavior like this as a race condition. This is just one of many papercut problems I witnessed while using Vim extensions, most of which I am not able to reproduce due to their flaky, race-condition-like nature.

Why this should be fixed: I think the upvotes of this issue show two things:

1. There is a very large interest in a Vim mode for VSCode.
2. Vim extensions are currently unable to provide an acceptable user experience for Vim users. (Why else would someone upvote this issue despite the possibility to use a Vim extension?)

Given the current extension host architecture, it does not look like an acceptable Vim mode is possible. This effectively treats Vim users as second-class citizens. If they choose to use VSCode they have to deal with typing latencies and other performance problems that would likely be considered unacceptable for the native editing experience of any other editor. The situation also wears out extension developers who have to fight an uphill battle against performance problems.

How this could probably be fixed: Various proposals have been voiced in the discussions surrounding this issue:

1. Running each extension in a separate thread. @alexdima has written down some thoughts on how to achieve this here. Despite the refactoring effort, the main downside seems to be the performance implication of running n extension hosts.
2. Running some extensions in a separate thread. Very performance-sensitive extensions (e.g. those using the type command) could run in a high priority thread while extensions that do not rely on very low latency use the main extension host. @alexdima argued that this would be just a "bandaid" not addressing the root cause of bad extension performance. I think this argument presupposes a false dilemma. One can both acknowledge the low latency needs of some extensions and address the bad performance of others at the same time.
3. Implementing a Vim mode into VSCode itself. This is the proposal made by OP. Since it would be a non-generic solution it could be tailored to the needs of Vim users without any compromises. However, it goes against the spirit of addressing niche needs in extensions, is quite probably the most expensive option to develop and does not address the needs of other extensions that use the type command. (What about rust-analyzer? Dance? etc.)

I might be wrong but I understand the popularity of this issue less as a verbatim call to implement a Vim mode in VSCode directly but rather as a general expression of discontent with modal editing in VSCode. I wrote this down as groundwork for potential future discussion.

Disclaimer: I have neither worked on VSCode nor on any extension. My knowledge of the causes of this issue stems entirely from posts of other developers, whom I might have misunderstood or misrepresented. Feel free to correct me, I will happily edit this post.

[rkatic]

Instead of implementing a specific multi modal system like VIM, which would require too much effort, it seems to me that it makes much more sense to focus on general issues that make those systems hard to implement properly with extensions.

Personally, I find the particular VIM system kinda outdated because of the verb-movement order, while movement-verb order can give real-time visual feedback before "committing" entire phrases. Also VIM is extremely opinionated, making it almost impossible to coexist with existent shortcuts/features at the same time.. which could make such additional mode a continues burden to maintain.

EDIT: Said that, I admit I'm not familiar with VIM mode in Sublime, and if it's a "lite" VIM mode, I guess such effort makes more sense.. since conflicting features could be omitted, making it less of a pain to maintain. But stil.. is it worth it? In meantime, popular extensions continues to have issues.

[rkatic]

I know me criticizing VIM will not be popular in this thread, but my point was that I believe VIM is not inline with modern editor's features like multi-cursors/selection, common and custom shortcuts, etc.. and forcing it breaks existent editor's features at some extent, and that was for me the major pitfall of these VIM extension that I tried. Then I tried an extension that implements kakoune, which although I don't use any more, was for me the prove that systems that are much more compatible/suitable with modern editors exists. How much of VIM should be integrated to somehow play nice with existent and future features of the editor? I suspect it is not a trivial question. Even if you hit a nice balance now, likelihood of realizing a VIM feature is becoming a pain to maintain with new features, is not small at all.

[thiagomajesk]

IMHO: Instead of implementing VIM mode, perhaps a better alternative would be supporting something like this: https://marketplace.visualstudio.com/items?itemName=johtela.vscode-modaledit natively.

Implementing a general/ configurable modal editing framework, at least allows users to better configure how the functionality is handled for their taste, be it VIM, Emacs, or Kakoune keybindings (in contrast to implementing something for a specific niche of people).

[ghost]

Just use VIM if you want it so badly? I don't see a reason why it should be integrated into vscode?

[dingolfsson]

Found this issue because both of the VIM extensions can be so buggy that I have to flat out disable them. Would LOVE VIM to be integrated into VSCode!

[astier]

@dingolfsson I don't think you actually mean integrate. If you want to integrate vim into vscode you would have to use https://github.com/asvetliakov/vscode-neovim because as its descriptions says its a VSCode Neovim Integration but you said its buggy. What you actually mean is you want vim to be rewritten from scratch and implemented in vscode.

Also did you report this bugs in the respective plugins? Because maybe it would be easier to just fix this bugs instead of rewriting vim in vscode. What makes you think a vim-rewrite would have less bugs than the current plugins.

[YalandHong]

@astier have you used the plug-ins yourself? Are you sure the existing shortcomings can be fixed without any help from the underlying platform?

If currently VSCode is lacking of APIs, it's definitely OK to add more. But this is far from enough to be a reason why VSCode should be bundled with a VIM-rewrite.

[dschuessler]

The latest Insiders Build, contains a new experimental setting that allows to execute Vim extensions in a dedicated extension host process. It is supposed to alleviate the latency problems of Vim extensions.

Configure the following in your settings.json and then reload the window or restart:

"extensions.experimental.affinity": {
    "vscodevim.vim": 1,
    "asvetliakov.vscode-neovim": 1
},

See the announcement here: https://github.com/microsoft/vscode/issues/65876#issuecomment-1078827200

[trkoch]

In the spirit of the announcement above, rather than implementing yet another extension, perhaps revisit some of the feature requests? Here is a feature request by the author of vscode-neovim. Implementing this would remove the need for many workarounds and fix bugs that are the result of this.

[wolonge95]

Jetbrains's IdeaVim is better. I often open JB’s IDE instead of vscode, although the IDE is very large and slow. There may be few people who need vim. Now VSCodevim has an annoying bug in the IME, and has not been fixed. For me, I need mode editing may not be consistent with VIM.

I always look at VSCode for some time, and experience. This time the Code-Server looks great, but VSCodeVim's IME BUG has not been fixed yet. It is a pity.

[Tinkering-Townsperson]

Try this: https://www.youtube.com/watch?v=-txKSRn0qeA It work great for me!

[GitMensch]

In the spirit of the announcement above, rather than implementing yet another extension, perhaps revisit some of the feature requests? Here is a feature request by the author of vscode-neovim. Implementing this would remove the need for many workarounds and fix bugs that are the result of this.

I totally second this. Can someone please reopen that issue "kind of counting" the upvotes on this issue "give me vim power" to the vim-extension's finding of a shortcoming in the platform, which would allow adding "vim power" as opt-in with a clean platform form the people that want it?

Can this issue be used as a "collection / check list" of specific issues that are necessary to be added, instead of an overall "add a mode to the platform itself"?

[softorangetech1122]

I don't utilize VIM myself, for the most part in view of terminal and difficult to-leave issues. In the event that it is ever a console easy route, imagine a scenario where I press it coincidentally. How might I at any point exit out of it? So this will create issues to individuals who don't utilize VIM. Leave an abhorrence on the off chance that you have something similar (on the actual issue, not this remark).