In other words, what features from neovim integration would you guys like to see implemented first?

Reading .nvimrc (mappings etc) and using plugins from vim/neovim in VSCode (everybody a lil bit a freak, do not judge me)

@FelikZ So for you, reading key mappings from .vimrc and plugins? What are the main plugins you're interested in?

@Chillee I would love to see support for following plugins:

• vim-fugitive
• tcomment_vim
• vim_surround

@aakashsigdel Surround and Commentary/Tcomment are both already implemented. Vim-fugitive support is something that seems very difficult/impossible even with full Neovim support (although I'm not ruling it out completely). Vim-fugitive is too closely tied to vim display elements (buffers, tabpages, splits, etc.)

I have some ideas about how it might be possible, but honestly, it seems unlikely that vim-fugitive will be able to be supported properly.

@Chillee
First of all I really really appreciated work that VSCode team being done. Thats awesome and most of my daily needs are already being covered, thanks for that.

What are the main plugins you're interested in?

Some of day-use plugins are missing (or partially missing).
plugins:

• argwrap - really really missing this one, extremely useful and if we look to a source it mainly using vim commands to do its magic;
• vim-easymotion - I am missing easymotion-sn (replacement for search, where you can navigate search results using tab and then jump to a specific place by a key) and easymotion-s2 which allows to use multiple symbols for jump;
• vim-unimpaired - features like line moving and spacing between lines are already being implemented in VSCode, so easy to bind and re-use. But some are missing.

key mappings from .vimrc

It is solvable by settings.json in current Vim plugin and so I moved most of mappings by hands. Most of them works as expected with some negotiable issues. I have spent a lot of hours doing this while reading them and adopting to VSCode automatically (where possible) from .vimrc/.neovimrc can save a lot.
But I understand that probably it does not make sense to support this since it is hard to implement/support and anyway will lead to errors due to differences/inconsistencies between editors. On other hand if complete vim implementation in VSCode will happen using neovim, then it will be loadable.

I think neovim should be used to do any heavy lifting and anything that you would have to write yourself. I should be able to farm out ex commands to neovim so that it can run external programs for me and what not. Also, I should be able to have settings and keybindings in my vimrc and not have to reproduce them again in a much more verbose way in settings.json.

I can see how many plugins will be rather difficult to implement. Usually vim plugins add language support, autocompletion, snippets, file finding, etc and those are all provided already by the editor and the editor extensions. I think the most useful vim plugins to add here are those that provide movement/navigation help (vim-repeat, vim-surround, vim-commentary, targets, vim-easymotion).

In general, I would love to see more automatically included keybinding support for doing vscode operations in a vim-like way. For example, I should be able to open up the terminal or switch to/from the file finder using leader or g commands. Also, diffing within the editor is something common that I do in vim (diffthis, diffoff, etc)

@offero

I should be able to farm out ex commands to neovim so that it can run external programs for me and what not.

Starting from the next release, you'll be able to offload all ex commands (except a couple) to neovim. Just set enableNeovim to true.

Also, I should be able to have settings and keybindings in my vimrc and not have to reproduce them again in a much more verbose way in settings.json

This is currently part of the plan. The way I'm imagining this working is by having a command that will sync between the settings.json and your .vimrc.

I think the most useful vim plugins to add here are those that provide movement/navigation help (vim-repeat, vim-surround, vim-commentary, targets, vim-easymotion).

Even something like easymotion is non trivial to implement through neovim. Easymotion's labels don't have a direct translation to Vscode.

In general, I would love to see more automatically included keybinding support for doing vscode operations in a vim-like way. For example, I should be able to open up the terminal or switch to/from the file finder using leader or g commands.

I disagree about this one. Although we've added things like <c-w> h to navigate between windows, things like what you've said are better left to the user's own keybindings.

My point about the keybinding support stems from the fact that when I use vscode even with the vim extension, my hand navigates to my mouse too much because I haven't been provided a natural/obvious way to perform some functions. Maybe it will just take more customization and learning on my part to get it all right and have a workflow where I don't have to go to the mouse any more.

When Vscode has an analogue for stuff that you can do in vim, like vsp or gt, we typically to implement it.

However, upon thinking about it some more, I think you might be right that we should implement some more vim like behavior.

Any places in particular where you find yourself using the mouse a lot?

Any places in particular where you find yourself using the mouse a lot?

File navigation
New tabs, splitting, closing a tab/split
Opening/closing console and debug menus
Running test under cursor (tooltip links let you run them)
Running debug task
Ctrl-E/Y stop working when the cursor reaches the top/bottom of the visible editor window, so I use the scroll wheel after that.
Toggle breakpoint, stepping in debugging

I know these already have some keymaps that I just haven't become used to yet, but they aren't my vim maps...

Another extension I use a lot is BufKill (:BD) that allows me to close out the active buffer without closing the split.

I just want to do everything with ex commands and leader key sequences!

Integration of Neovim is very exciting news. Thank you for doing this!

What currently keeps me from using VSCode is its limited ability for window layouts, see microsoft/vscode#14909. Therefore, what I would like to see is that Neovim handles the buffers / splits within an editor window in VSCode.

@eglimi Unluckily, that's not likely to come in the near future. There's a fundamental difference between vscode windows/tabs and what they're capable of.

I've thought of how we might be able to embed neovim views into VSCode, but any work on that is still a long way off.

@GaryFurash Unluckily, VSCode's support for native dependencies is a bit lacking. See microsoft/vscode#6929

We might still do it (especially if we decide to make neovim a required dependency), but we need a bit of discussion (and more testing of neovim) on that front.

@Chillee my 2 cents:

• Its good to have NeoVim integration for those who want it
• NeoVim should never become a mandatory/required dependency
• Optional is ok, depending on what that means. But it shouldn't mean a too-significant chunk of time/code will be spent on stuff that only benefits NeoVim users
• NeoVim shouldn't be bundled with VScodeVim. Almost all systems have Vim already included. Why introduce needless complexity? What about people who don't use external commands at all? You'd just include a useless binary for them

All in all I'd say: create hooks for the people who use NeoVim thus giving them the possibility to do what they want, but develop for the system Vim. This strikes the perfect compatibility balance between NeoVim, Vim, and pure VScode users.

@JORVI Here are my thoughts:

• I don't understand what you mean by "stuff that only benefits NeoVim users". If somebody can use neovim in vscodevim, then that benefits vscodevim users.
• I don't understand your last point either. What does a system having vim already included have anything to do with including neovim? The idea behind Neovim integration is that we won't be limited to only Ex-commands: Ex-commands were only the beginning.

create hooks for the people who use NeoVim thus giving them the possibility to do what they want
That's also infeasible. Basically, if this extension is not integrating neovim, then neovim integration won't happen (unless it's an entirely new extension).

... but develop for the system Vim.
In general, you seem to be advocating for developing for Vim integration instead of Neovim. That is impossible. We are not using Neovim simply because it's fashionable or due to any personal preference, but because only Neovim has provided the API calls that are needed for integration.

As a side note, this github issue was created for feedback, so I'm going to clean up some of the help comments that are fixed or moved to another issue.

#1794

@Chillee

I don't understand what you mean by "stuff that only benefits NeoVim users". If somebody can use neovim in vscodevim, then that benefits vscodevim users.

That only benefits the subset of VScodeVim users that will use the feature(s) that engage NeoVim. See my next point.

In general, you seem to be advocating for developing for Vim integration instead of Neovim. That is impossible. We are not using Neovim simply because it's fashionable or due to any personal preference, but because only Neovim has provided the API calls that are needed for integration.

Yes, I am advocating for targeting Vim instead of NeoVim, because adding an external dependency is annoying. Making it mandatory is even worse, and including NeoVim, even for people who never use Ex-commands seems like unnecessary bloat. I can also see a future where there will be the choice: either implement a feature the easier way by making some calls to NeoVim, or the harder way by implementing it natively.. if the choice gets made that the easier road will be be taken, you've suddenly divided your userbase (NeoVim vs 'minimal' users).
On that note: wouldn't it be possible to use Vim's client-server mode to work some magic? It'd massively increase the reach of whatever extra stuff you develop.

The entire premise of neovim is to provide a fast API to vim for integration with other editors.

@offero that's just plain wrong. The starting premise of NeoVim was async support, and the premise now is a cleaned-up version of the Vim codebase that allows for more extensibility of Vim. Nowhere does it say one of the explicit goals is to allow other editors to hook into NeoVim.

@VSCodeVim devs
To be clear: I'm not against exposing some NeoVim functionality to VScodeVim, I'm merely saying that most of your users will never use Ex-commands or NeoVim, and developer resources ( = time) are finite. Focusing those finite resources on developments that benefits all users vs. that only benefit the small subset of your users that will actually need to hook into NeoVim seems like a no-brainer to me. Likewise, not requiring a dependency for something only a small subset of your users needs seems again, a no-brainer, but ultimately it is your decision.

@JORVI
From the homepage. 1 of 4 primary features. https://neovim.io/

First-class embedding
GUIs can nvim --embed or communicate via named pipe using the discoverable msgpack API.

From https://www.bountysource.com/teams/neovim/fundraiser

neovim
What you should know about neovim, if nothing else:
It will provide first class support for embedding.
It lets you extend the editor in any programming language.
It supports more powerful GUIs.

@offero damn.. I have no idea how I read over that. At any rate, I think I've advocated the native/minimalist viewpoint strongly enough, I'll shut up now and see where the discussion goes :)

@JORVI I agree: As it currently stands, it is probably a bad idea to bundle neovim in with the extension. However, we might potentially want to integrate more and more of neovim into VSCodeVim. The undo tree, .vimrc settings, actual support for vim plugins, fixing the long tail of bugs that come from subtle differences in how vim is implemented, etc.

If/when those features drop, they would require neovim as a dependency. And as such, we would have 3 options:

• Force users to install neovim themselves (this is annoying, as you said)
• Maintain both a non-neovim version and a neovim version (This is untenable as an open source project. One of the most limited resources open source projects have is developer time, and supporting 2 versions is not something I am willing to do)
• Bundle neovim in as a dependency/ run an install script

The 3rd option seems like the best one to me.

Note: As I said earlier, vim is not suitable for providing an API around. If we want any of the features I listed above, they will have to come from neovim.

I think that there will be a point where this package becomes so integrated and dependent on neovim, that it will be required to have neovim as a dependency. At which point, there will be people that would prefer the "legacy" version without neovim support and someone in the community that wants this version can fork the project and maintain their own plugin. You should not be the one to have to maintain two versions.

I had never heard of Neovim until this latest update. Looking into it, it sounds like a good idea. I would like to suggest modifying the readme file a bit to help show people why you're encouraging a dependency. You could either borrow text from or link to the Neovim website where it gives a good reason as to why Neovim is worth my time installing. Another link I found helpful, but may not be as necessary is their vision.

I would like to share my perspective as a very happy vscode and VSCodeVim user. I wouldn't use vscode without VSCodeVim, and I am grateful for all your work.

I would like to second @JORVI's point that, at least for me, the VSCodeVim emulation is good enough, and I don't need all of vim's features to be happy. If I wanted all of vim's keybindings and support for custom plugins, I would use (neo)vim instead of vscode. But what I really want is vscode's awesome language plugin support and its modern GUI, and so that's why I use vscode.

I worry that integrating VSCodeVim with neovim will be a tricky project that might make the extension work less well. For example, it seems difficult to integrate neovim's undo tree with a potential vscode-native undo tree.

Whenever vscode tells me VSCodeVim has a new update, I am excited to see what vim shortcuts I can now also use in vscode. Though better ex commands is nice, I found the release notes for 0.8.2 concerning since I really don't want VSCodeVim to break, and that's what encouraged me to comment here.

I know this doesn't quite answer the question "what features from neovim integration would you guys like to see implemented first", but I hope it's useful feedback anyway. Thanks for the plugin.

@CavalloneChen Is your vscode flatpak version?

Honestly I don't know. I'm using the build downloaded from Vscode's official website.

Execute flatpak list in terminal, and check if there is a line like this com.visualstudio.code

================================

I guess you download a .deb file from the visual studio code website, that's how I get a flatpak version vscode. I uninstalled the flatpak version vscode first, and manually add package repository then install vscode from package manager.
( referenced from here: code.visualstudio.com/docs/setup/linux )

I copied the installation commands for you:

curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > packages.microsoft.gpg
sudo install -o root -g root -m 644 packages.microsoft.gpg /usr/share/keyrings/
sudo sh -c 'echo "deb [arch=amd64 signed-by=/usr/share/keyrings/packages.microsoft.gpg] https://packages.microsoft.com/repos/vscode stable main" > /etc/apt/sources.list.d/vscode.list'
sudo apt-get install apt-transport-https
sudo apt-get update
sudo apt-get install code

P.S.
Commands uninstall the flatpak version vscode:

flatpak uninstall <the vscode name shown in 'flatpak list', e.g.  com.visualstudio.code.oss>

Thanks for your explanations, I really appreciate your effort. I found that I made a fundamental mistake. I pointed the neovim path to the neovim installed on my remote machine, but the local neovim path should be pointed instead. My problem was solved after I changed to the local path.

I am perfectly happy with current vscodevim as far as my current knowledge of vim goes, great job.
Yet to be honest I'm a bit surprised you're trying to implement vim and neovim emulation into vscode natively, wouldn't it be easier (but also better for long-term maintenance) to connect to full neovim through server mode and basically have neovim do all the work for you, so that you're not really emulating [neo]vim, you're actually using it, just with vscode as frontend?
Or have I misinterpreted what's currently possible through neovim APIs?

By the way, for those that oppose this "because minimalism", I would note that baking neovim's functionalities into vscodevim doesn't make it any lighter than bundling neovim with it (the code's getting in either way), nor any simpler for the user (as long as it's installed automatically with it). It only makes it harder for the devs that maintain the plugin.

@Mirag-e There is a project to do just this (https://github.com/Chillee/VSCodeNeovim) but it's been dead for a while. You might find https://github.com/onivim/oni2 interesting also.

thanks for the pointers, oni2 seems super interesting, though i'm a bit sad it's not fully open source. I guess that's the price to pay when you don't have microsoft paying your main developers.

I wish VSCodeNeovim was active. I'd work on it myself if I have the time, but, alas...

Ex commands may be useful, but I've never actually used them. The VSCodeVim plugin seems to work well a lot of the time, but I find it to be a bit finicky sometimes, which is why I personally would love to see neovim power it.

Oni2 looks super interesting, since they intend to support vscode extensions and configuration... and for $20, I don't mind speculating that the project will work out. Time will tell.

Oni2 looks super interesting, since they intend to support vscode extensions and configuration... and for $20, I don't mind speculating that the project will work out. Time will tell.

I'm not trying to discourage you to support this cool project. Just FYI after using Oni (1) I dropped it fairly quickly. (it was finicky about what neovim versions I had installed and it was buggy)

Oni2 looks super interesting, since they intend to support vscode extensions and configuration... and for $20, I don't mind speculating that the project will work out. Time will tell.

I'm not trying to discourage you to support this cool project. Just FYI after using Oni (1) I dropped it fairly quickly. (it was finicky about what neovim versions I had installed and it was buggy)

Thanks for the heads up. It seems they've taken a different approach with Oni2 though, using libvim instead of neovim. I read somewhere that the choice was because of integration issues with neovim.

You may already know this, but it seems like if you have supported Oni1, you will have access to Oni2 https://onivim.github.io/docs/other/faq#i-already-backed-onivim-1-do-i-need-to-pay-again so hopefully your support for Oni1 will be worth it if Oni2 is successful.

I installed Neovim and set it active in order to be able to use regular expressions in the substitute command. However, it does not seem to work for the substitute or global command.

If I use:

":%s/^/<p>/g" (to insert a p tag in the beginning of all lines)
or
":g/^\s*$/d" (to remove all blank lines)

I get the error:
"TaskQueue: Error running task. Failed to handle key= . nvim_buf_set_lines: Wrong type for argument 1, expecting Buffer."

Any ideas about how to make this work?

I installed Neovim and set it active in order to be able to use regular expressions in the substitute command. However, it does not seem to work for the substitute or global command.

If I use:

":%s/^/<p>/g" (to insert a p tag in the beginning of all lines)
or
":g/^\s*$/d" (to remove all blank lines)

I get the error:
"TaskQueue: Error running task. Failed to handle key= . nvim_buf_set_lines: Wrong type for argument 1, expecting Buffer."

Any ideas about how to make this work?

+1 @Orionsg This feature had been working for me for quite some time but it has been broken recently :/ Similar error message about nvim_buf_set_lines tried upgrading neovim to no avail. I'm thinking it's a bug.

One thing I miss is netrw being able to open a url with gx is really nice.

I have also recently started seeing the error: "TaskQueue: Error running task. Failed to handle key= . nvim_buf_set_lines: Wrong type for argument 1, expecting Buffer.".

As an additional data point I also get the error when I try to run a non-existent command, like :blah.

I installed Neovim and set it active in order to be able to use regular expressions in the substitute command. However, it does not seem to work for the substitute or global command.

If I use:

":%s/^/<p>/g" (to insert a p tag in the beginning of all lines)
or
":g/^\s*$/d" (to remove all blank lines)

I get the error:
"TaskQueue: Error running task. Failed to handle key= . nvim_buf_set_lines: Wrong type for argument 1, expecting Buffer."

Any ideas about how to make this work?

I also got the nvim_buf_set_lines: Wrong type for argument 1 error message when I executed the :%s/a/b/ command.

I'm sure the latest Vim 1.11.0 version caused this issue, and downgrade to the Vim 1.10.2 can fix it.

For the nvim_buf_set_lines: Wrong type for argument 1 issue that has popped up on the latest vscodevim version (1.11.0), see #4126 with a fix incoming #4169.

With this thread growing to the size it has, it has inevitably become an all-encompassing dumping ground for all neovim-related bugs and has made it hard to track individual bugs that people have encountered. As such, I'm going to close this issue. If you encounter an issue with neovim integration or vscodevim in general, please file a new issue (or search through existing issue) with repro steps, etc.

Sorry for bumping this thread. For anyone interested i made experimental neovim integration. (ext: vscode-neovim). You might want to give it a a try.

@asvetliakov Cool! Are you aware of https://github.com/Chillee/VSCodeNeovim?

@J-Fields Yes, actually i've been hoping for a long time it would become complete usable integration. But unfortunately that didn't happen 😄

@asvetliakov Nice job! I've been wanting to get back to working on that for quite some time, but I just haven't had the time to do so.

@asvetliakov Awesome news. Looking forward to read the code!

Where does the output of ex commands go? For example, if I do :!echo hi, I don't see the output anywhere. I can redirect to a file I suppose with :!echo hi>file.txt, but that's not what I'm looking for.

tl;dr: Where is stdout for ex commands?

Yanking with the global command always put everything into the default register, and the 'append to register' command always add a copy of the last item to the beginning.

commands:
:g/pattern/y a
:g/pattern/y A

test content:

pattern 1
pattern 2
pattern 3
pattern 4
another text 1
another text 

I'm trying to copy current line to previous cursor line using :t'' but I get E20: Mark not set

Eventually I want to implement this mapping cnoremap $t <CR>:t''<CR> So that I can do something like ?foo$t

:<,>s/old/new/g just replace the first match word in the file

:<,>s/old/new/g just replace the first match word in the file

This command is working when neovim integration is disabled

I mapped (leader) space + n as :noh in my init.vim of neovim which works fine in native neovim:

map <Space>n :noh<cr>

However, this key mapping is not working when using neovim vscodevim in vscode. Have I missed anything important here?

When using remote development, neovimPath must be a path on the local machine, not the remote. This is confusing. Is there any way to make this clearer to the user? Is there any way to indicate that this setting should not be overridable in remote development, and the local setting should always be respected?

Supposing I use two laptops to connect to the same remote ec2 instance. The laptops have different paths for neovimPath. This will break, because I have to set neovimPath on the remote ec2 instance's settings.json, but that path needs to point to the laptop's local neovim binary.

I think that the scope setting is wrong. It is "machine" but should be "application."

https://code.visualstudio.com/api/references/contribution-points#contributes.configuration

A configuration setting can have one of the following possible scopes:

• application - Settings that apply to all instances of VS Code and can only be configured in user settings.
• machine - Machine specific settings that can be set only in user settings or only in remote settings. For example, an installation path which shouldn't be shared across machines.

I mapped (leader) space + n as :noh in my init.vim of neovim which works fine in native neovim:

map <Space>n :noh<cr>

However, this key mapping is not working when using neovim vscodevim in vscode. Have I missed anything important here?

Seems that I have to add the following in the settings.json of vscode explicitly:

    // [-] map Space+n to :noh to remove highlights in normal mode
    "vim.normalModeKeyBindings": [
        {
            "before": ["leader", "n"],
            "commands": [":noh"]
        }
    ],

Also see vscode-neovim/vscode-neovim#1789

If I understand correctly, VSCodeVim can't use Neovim extensions, right ?

If I understand correctly, VSCodeVim can't use Neovim extensions, right ?

You are right, it can't use neovim extensions... But some are pretty helpful, leap.nvim is one of them, there's even a PR for an implemented version in normal vscodevim, with 2 years now...

Btw it seems this neovim integration is dead... The vscode neovim extension doesn't even use commands in statusbar and many things are not right, this implementation should continue.