# vscodevim ships a package called vim and last released in December

> VSCodeVim is a MIT licensed TypeScript project that emulates Vim inside Visual Studio Code, with a built-in emulation mode and a separate Neovim integration, eleven popular Vim plugins reimplemented rather than loaded, and a Mac-specific installation step that edits system preferences. The mechanics are well documented and slightly more opinionated than the name suggests, most visibly in that it claims your control keys by default.

**VSCodeVim/Vim** — :star: Vim for Visual Studio Code

- Repository: https://github.com/VSCodeVim/Vim
- Website: http://aka.ms/vscodevim
- Stars: 15,217 · Forks: 1,467
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/vscodevim-vim

## The package is called vim and the extension identifier is vscodevim.vim

The manifest names the package vim, with a display name of Vim, published by an organisation whose identifier is vscodevim.

So the extension identifier that appears in a settings file or a marketplace URL is the publisher and the package name joined by a dot, and the package name is the single most generic word in the ecosystem.

That is worth knowing before you look for it. Searching a registry for vim will not find this, and the human-readable name it presents is identical to the editor it is imitating, which makes the extension easy to confuse with the editor in a list of installed extensions.

It is installed from two places, a marketplace listing and an open registry listing, both keyed on that same identifier. So there is one canonical extension and two distribution channels, which is good for users on editor builds that come from the second.

The manifest also declares the editor version it supports, with a floor set at a two-plus-year-old build. That is a deliberate choice for a Vim emulator, since the people who want Vim keybindings are disproportionately likely to be running whatever editor build their organisation standardised on rather than the newest one.

## The newest release is from December 2025

Read the release list against the commit activity and there is a gap of about ten months.

The three most recent releases are 1.32.4 from December 2025, 1.32.3 from December 2025, and 1.32.2 from December 2025. Three patch releases in two weeks, then nothing.

The default branch last took a push on 2026-09-26, and the repository is not archived. So there has been roughly ten months of commits since the last tag, and the version that installs from either marketplace is the December one.

Two details make that gap more concrete. The manifest carries no beta or pre-release marker in its version, so there is no signal in the published version number that it is behind; it simply reads as a current patch release. And the change log is split across two files at the top level, one current and one carrying an older suffix, which is what a documentation or history migration looks like from the outside.

For an extension, ten months is survivable, since the editor API moves slowly and most users never notice. But if you are adopting this for a team, the version on the marketplace is the version to test, not the version on the branch.

## Key repeat on macOS takes six system preference edits

The Mac installation section is the longest part of the installation documentation, and it is not about installing anything.

The extension itself installs from the marketplace or the open registry. What macOS then requires is a system-level change, because a key press and hold produces a contextual menu rather than repeating, which breaks Vim's count and repeat actions. Six commands fix it, each writing the same preference to a different domain:

```sh
defaults write com.microsoft.VSCode ApplePressAndHoldEnabled -bool false              # For VS Code
defaults write com.microsoft.VSCodeInsiders ApplePressAndHoldEnabled -bool false      # For VS Code Insider
defaults write com.vscodium ApplePressAndHoldEnabled -bool false                      # For VS Codium
defaults write com.microsoft.VSCodeExploration ApplePressAndHoldEnabled -bool false   # For VS Codium Exploration users
defaults write com.exafunction.windsurf ApplePressAndHoldEnabled -bool false          # For Windsurf
defaults delete -g ApplePressAndHoldEnabled
```

There is one for the stable editor, one for the insider build, one for the open-source fork, one for the fork's exploration variant, and one for another editor in the same family. The last line deletes the preference globally rather than setting it.

Then two further instructions: log out and back in, and restart the editor. And a recommendation to raise the key repeat and delay settings in the system keyboard preferences as well.

So enabling this extension on a Mac means editing the defaults of five editor domains plus the global domain, signing out, signing back in, and changing two system keyboard settings. None of that is reversible from inside the editor, and none of it is mentioned in the extension's own settings.

It is a real cost for what is a quality-of-life feature, and it is a reminder that a Vim emulator inherits an operating system's input model, not just a keyboard layout.

## It takes your control keys by default, and you have to give them back

The Windows installation section contains one paragraph and it is the most important sentence on the page for anyone who already uses the editor.

Like real Vim, the extension will take over your control keys, and this behaviour can be adjusted with two named settings.

So the default is that editor shortcuts stop working. The control combinations people reach for constantly, including select all, copy, cut, paste, undo and select next occurrence, are reassigned to their Vim equivalents, which is correct if you are a Vim user and maddening if you are not.

The documentation mentions this under installation for Windows specifically, but the behaviour is not platform specific, because it follows from the mode system rather than from the key names. The setting that keeps the editor's own bindings is a boolean you have to turn on, and the other named setting gives you a way to decide per key what happens.

That second one is the more useful of the two for anyone who wants a hybrid: you can keep the editor behaviour for the handful of combinations you actually use for editor actions and let Vim have the rest.

## The settings reference is deliberately incomplete, and the real one is in the editor

The settings section opens with a disclaimer that tells you where the actual documentation lives.

It says the settings described on the page are a subset of the supported settings, and that the full list is in a features tab on the extension's details page, found through the extensions view in the editor.

So the README is not a settings reference. It is a selection, and the authoritative list is a tab inside a marketplace listing rendered by your editor.

That is an unusual choice for a project with a documentation site and a repository this size, and it has a real cost. You cannot search the full settings list, you cannot diff it between versions, and it is unavailable to anyone reading the repository rather than using the editor.

What the page does cover is the genuinely confusing parts, and it covers them well: whether control keys are taken, how to remap in each of the four Vim modes, whether remappings apply recursively, how to debug a remapping that is not firing, and how to write a multi-key combination. Those are the questions the settings table cannot answer.

The table that is present lists settings with a description, a type and a default, which is the right shape for what it includes.

## Eleven popular plugins are reimplemented rather than loaded

There is a whole documentation section on emulated plugins, and the list explains something fundamental about what this project can and cannot do.

You cannot load real Vimscript in Visual Studio Code. There is no Vim runtime in the editor, no plugin host for Vim plugins, and no way for an arbitrary plugin to register its own commands.

So the eleven most requested plugins are reimplemented in the extension's own language: an airline status line, easy motion, surround, commentary, indent object, sneak, camel case motion, an input method, replace-with-register, and two text object plugins for whole files and argument lists.

The trade-off is real in both directions. What you get works without a Vim installation, updates with the extension, and behaves consistently. What you give up is the actual plugin, so anything outside these eleven is unavailable, and the ones here are approximations of behaviour you may already rely on in detail.

There is a second path around the same problem. The settings section documents a Neovim integration, which is a different architecture: rather than emulating Vim, it talks to a Neovim instance, and then the real plugin ecosystem is available.

So the choice is emulation versus integration, and it decides both your fidelity and your plugin set.

## Two changelog files and a packaging note left in the README

Two small artefacts at the top of the repository say more about the project's history than any of the feature documentation.

There are two change log files side by side, one with the current name and one carrying an older suffix. The README points readers at the current one for breaking, major and minor updates between releases, which implies the other holds history that has been moved rather than deleted.

That is a reasonable way to keep a long change log within a repository that a browser renders slowly, and it is also a thing a reader has to know about, because searching the repository for a past release note finds it in one file or the other depending on its age.

The second artefact is a development note left in an HTML comment near the top of the README, asking whether a different publishing tool should be used because the current one will not package the page as intended. It does not render on the page, but it is committed, and it describes a live problem with the release toolchain.

Neither is a defect. Both are the kind of residue that accumulates in a long-lived project, and both are more informative about its maturity than a clean front page would be.

## Conclusion

VSCodeVim suits someone who already has Vim muscle memory and wants it inside an editor built for everything else, and who is willing to read a settings reference that lives in a tab inside the extension listing. Three things to decide first. Whether the built-in emulation is enough or you want the Neovim integration, since those are different architectures with different fidelity. Whether to hand back your control keys, since the default takes them and the setting to avoid that is not enabled by default. And how you pin, because the newest release is from December 2025 while the branch has moved on since.

## FAQ

### Can I use Vim with VSCode?

Yes, through this extension, which is a Vim emulator written in TypeScript rather than a wrapper around a real Vim. It is installed from the marketplace or the open registry, provides Vim modes, remapping and a command line, and offers a separate Neovim integration as an alternative architecture.

### Is vim actually better than vscode?

The project makes no such claim and the front page offers no opinion about editors. What it describes is what the extension does: mode handling, key remapping per mode, multi-cursor support, a subset of popular Vim plugins reimplemented, and a Neovim integration path.

### Which is better for VSCode, Neovim or Vim?

The extension supports both, and they are different architectures rather than competing options. Its default is an in-process Vim emulation, which needs no external Vim and reimplements a fixed set of popular plugins. Its alternative is a Neovim integration, which talks to a Neovim instance instead and therefore makes the wider Vim plugin ecosystem available. The documentation does not recommend one over the other.

## Sources

- [License: MIT](https://github.com/VSCodeVim/Vim/blob/master/LICENSE)
- [Project website](http://aka.ms/vscodevim)
- [README](https://github.com/VSCodeVim/Vim/blob/master/README.md)
- [Releases](https://github.com/VSCodeVim/Vim/releases)
- [VSCodeVim/Vim on GitHub](https://github.com/VSCodeVim/Vim)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vscodevim-vim