Chillee commented 7 years ago

We have now added Neovim integration for Ex-commands. Enable it with vim.enableNeovim. Note that you must have neovim installed for this to work.

What are opinions on neovim being an optional dependency / maybe becoming a mandatory dependency down the line? We might be able to bundle it together with the extension down the line.

People clearly want neovim support. What are the main reasons for that? In other words, what features from neovim integration would you guys like to see implemented first?

Also, please come to http://vscodevim.slack.com! We'd love to hear discussion in there (discussion/feedback tends to be a bit quicker in there).

FelikZ commented 7 years ago

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)

Chillee commented 7 years ago

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

aakashsigdel commented 7 years ago

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

vim-fugitive
tcomment_vim
vim_surround

Chillee commented 7 years ago

@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.

FelikZ commented 7 years ago

@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.

offero commented 7 years ago

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)

Chillee commented 7 years ago

@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.

offero commented 7 years ago

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.

Chillee commented 7 years ago

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?

offero commented 7 years ago

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!

eglimi commented 7 years ago

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.

Chillee commented 7 years ago

@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 commented 7 years ago

It would be cool if a slim neovim was installed automatically based on your own OS into some subdirectory of VSCode.

-- gary furash | furashgary@gmail.com, 520-907-2470

On Fri, May 26, 2017 at 1:54 PM, Horace He notifications@github.com wrote:

@eglimi https://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/VSCodeVim/Vim/issues/1735#issuecomment-304385958, or mute the thread https://github.com/notifications/unsubscribe-auth/AOT5tTsRxxqNe3T4ukSmskDhZ9a5FLSnks5r9zvugaJpZM4Nh7Uw .

Chillee commented 7 years ago

@GaryFurash Unluckily, VSCode's support for native dependencies is a bit lacking. See https://github.com/Microsoft/vscode/issues/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.

foldback commented 7 years ago

@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.

Chillee commented 7 years ago

@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

foldback commented 7 years ago

@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.

offero commented 7 years ago

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

foldback commented 7 years ago

@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.

offero commented 7 years ago

@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.

foldback commented 7 years ago

@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 :)

Chillee commented 7 years ago

@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.

billyvg commented 7 years ago

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.

mattferderer commented 7 years ago

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.

jellevandenhooff commented 7 years ago

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.

ghost commented 7 years ago

I'm a vim neophyte and am not very familiar with neovim. So I'm not sure if I have any feedback intrinsic to the neovim functionality, except to ask perhaps for some kind of overview into the functionality added for us ignoramuses?

Also, I wholeheartedly agree with what @FelikZ said with argwrap above. This would be awesome. I've been doing a lot of TypeScript recently, and I use objects as params for named parameters among other reasons. I find myself hitting i enter caps(esc) 3 w and repeat to separate args line by line countless times throughout the day. I've thought of recording a macro, but the functionality in argwrap would be ideal.

Thanks for the awesome product! :+1:

Chillee commented 7 years ago

@jellevandenhooff I appreciate the feedback. Too often, open source projects only get comments from people wanting new features / unhappy with the current state of the project, when the vast majority of users are very happy with how the project is going.

We'll definitely try to prevent making any regressions as we continue to add improvements. That was an extraordinarily large update, and we pushed out fixes for the main breaking fixes within half a day.

Chillee commented 7 years ago

@bill-mybiz So far, all we have is https://github.com/VSCodeVim/Vim#neovim-integration

offero commented 7 years ago

In general, I am all for simplicity and usability as well. I feel that plugins like vscodevim have to reimplement all of the functionality already provided through vim and make the plugin as vim-like as possible. Along the way, you have to fix bugs and tweak things that are simple vim features. I run into vscodevim bugs all the time. For instance, I just ran into a copy/paste from register bug where the register is overwritten if you paste from it. This is the kind of bug that wouldn't even show up if vim is being used under the hood because it's been thoroughly tested already.

If the neovim api doesn't fit well with the code, then I prefer to keep it simple and standalone. If neovim is a good fit, then I prefer to use it for as much as you possibly can.

I, too, am a happy VSCodeVim user. I wouldn't be able to use VSCode without this plugin, so thanks to the devs for all of their work to make our favorite new editor even better. Contention and dialogue are not bad in and of themselves, and your efforts are certainly appreciated.

mwedgwood-rmn commented 7 years ago

I'm a long-time vim user but haven't tried neovim yet. It sounds like integrating will open up lots of possibilities, but I found the readme description disorienting. Neovim integration is good for developers, but it's the features that users care about. As a user, I don't know what "neovim integration for Ex-commands" gives me, but "Faster search and replace" sounds like something I want.

I see a few responses here echoing the sentiment that the change isn't well explained. I'd encourage you to focus on documenting from a feature perspective but making it clear which features require neovim.

Faster search and replace (requires neovim)
Full ex-mode support (required neovim)

johnfn commented 7 years ago

As a user, I don't know what "neovim integration for Ex-commands" gives me

It means that we use NeoVim for ex commands. An "ex command" is the name in Vim for anything that happens after typing : and before enter in normal mode.

Could you suggest a better phrasing?

mwedgwood-rmn commented 7 years ago

Sure, @johnfn. If I understand the feature correctly, I would phrase that as some variation on "Full ex-mode support (requires neovim)"

ianks commented 7 years ago

This feature is awesome! I am loving this integration so far. Makes using VScode much simpler.

One point of feedback I have so far: s/search/replace/cg should allow you to choose which instances you replace :smile:

Chillee commented 7 years ago

@ianks We can't do anything about that yet. When this gets implemented on the neovim side, https://github.com/neovim/neovim/issues/6201, then we can add proper support :)

Well, we could add our own implementation, but I'd rather wait and solve it properly.

Chillee commented 7 years ago

I've started work on some basic plugin/.vimrc support here: https://github.com/VSCodeVim/Vim/pull/1840 (it works for targets.vim!)

I might write up a document sometime soon about how I plan on integrating Neovim.

binary132 commented 7 years ago

set your "vim.neovimPath"

You need to clarify this to indicate WHAT you are supposed to set it to (the path to the nvim/nvim.exe executable.)

Chillee commented 7 years ago

Some early work on a full rewrite based around neovim!

https://github.com/VSCodeVim/Vim/pull/1897

leoj3n commented 7 years ago

This doesn't support commands like ls that display a result using hit-enter, does it?

Chillee commented 7 years ago

@leoj3n Unluckily, it doesn't. I wish it did. There's an issue somewhere on neovim for this, but it's kind of hard to keep track of this stuff :/

If it did, we could get things like s//gc to work, etc.

trippel commented 7 years ago

My answer might be a little late, but better later than never. ;)

First of all: I really love the work you are doing guys. VSCode would be absolutely useless without this great extension. There are some minor bugs or lack of functionality which I could work around pretty well and overall I am really satisfied so far.

I would not mind having nvim as a mandatory dependency, being it shipped with the extension or not.

Chillee commented 7 years ago

@trippel Not at all! Neovim integration is a WIP, and any feedback is appreciated :)

tonyhb commented 6 years ago

THIS IS AMAZING!!! OMG! Can we have neovim read ~/.config/nvim/config.vimrc to autoload all settings and Plug extensions?

Edit: https://github.com/VSCodeVim/Vim/pull/1897 - huh. Awesome!

ghost commented 6 years ago

@chillee I'm not sure if somebody has mentioned this before, but it would be awesome if you could integrate the terminal output from neovim into VS code. For example I have the fzf.vim plugin installed, and upon calling it it lists all files like this:

https://i.imgur.com/rniK0AC.png

Now, I know that fzf isn't necessary because of vs's integrated ctrl+p search, but I just gave it as an example.

Chillee commented 6 years ago

@paxy97 I'm on mobile so I can't really check, but how does fzf display its output? Does it create a split and then use nvim's built in terminal?

Supporting stuff like this (also nerdtree /quickfix list) is something I'd like to do, but one problem is that we don't really have a good place to store this kind of output.

Chillee commented 6 years ago

Also, development has now moved to https://github.com/chillee/vscodeneovim for development purposes, so please open issues there!

Note that there are a lot of bugs we're aware of that make it unsuitable as a daily driver, so please mainly open feature requests/suggestions.

Chillee commented 6 years ago

@paxy97 So because we're syncing buffers, it kinda works? The highlighting doesn't match what it should be like in vim, it has to take up the whole page, etc. But the keybindings and stuff all work, so I guess if there's something you're really desperate for.

There's no really "good" way of displaying the UI though. We can't really customize splits nearly enough.

One thing I thought might be possible is displaying it in the built in terminal? I'm not really sure if that's possible though, nor desirable. So upon opening a buffer like the one for ctrl-p or NerdTree, the integrated terminal would pop up and the buffer would open in an instance of neovim in there.

ghost commented 6 years ago

I agree about the terminal that it's not a good idea. And opening it in a buffer isn't pretty either. But it's not that big of a deal for me, I'm happy as long as completion works :)

Chillee commented 6 years ago

@paxy97 I think we'll probably be syncing it to some kind of neovim window for 3 main reasons: first, if vscode ever adds proper support for split control, then we'll be able to mimic it almost perfectly. Second, I think it's a cleaner solution than forcing vim to close every single one of those buffers. And finally, if you really need to have something like this (maybe undo tree) or something like that, it'll still work.

Chillee commented 6 years ago

@FelikZ @offero So as it turns out, it is actually possible to offer full Easymotion support! There are some inherent limitations to the vim version that we don't necessarily have (like actually changing the buffer, as well as showing only matches on the screen), but I think it's still pretty cool.

Standard mapping (<leader><leader>w)

Doing map <Leader>L <Plug>(easymotion-bd-jk) and then <leader>L

FelikZ commented 6 years ago

@Chillee correct me if I am wrong. If I install latest neovim + easymotion plugin to it, then enable it in VSCode + will execute map <Leader>L <Plug>(easymotion-bd-jk), I will able to work with it in VSCode using <leader>L? All other easymotion's will be supported to?

VSCodeVim / Vim

Neovim Integration Feedback #1735

1794