Arch Linux

This would probably require a to-do list. Assigning to the VIM maintainer to get his opinion/help here.

Why not do the same thing as what gvim does which is, make neovim provide vim?

That would avoid a mass rebuild and would make every aur vim plugin compatible with neovim.

You are right, this would solve the problem. But it's not as clean as my solution imho. The gvim package actually includes /usr/bin/vim, which really is vim. If neovim is marked to provide vim, there should be /usr/bin/vim included in it as well, which is not the case by default. Of course this can be fixed by a symlink, but then /usr/bin/vim wouldn't really be vim, but neovim. I'm not sure about how much the differences matter, I'm not that much of a power user.

I'm the last person who wants to enforce a big rebuild of packages. If I had the rights, I'd do it myself, of course. I just wanted to point out that I think this would be a clean implemention. Isn't this one of the reasons vim-runtime was created for in the first place? Frankly I can't remember it too well.

What I'll do now is wait for your decision and I can inform the neovim-git maintainer in case there's changes to be done in his package.

The neovim package does not have an extra runtime files package and it does not depend on vim-runtime so I think that
making all vim plugins depend on vim-runtime does not help. The best option would to give a dependency for every plugin
on either 'vim' or 'neovim' but that is not possible currently, so I would go with making neovim provide vim which is good enough
since backwards compatibility is a high priority at the moment for neovim developers.

neovim can not provide vim in a technically correct way, one of the main reasons for the fork was to remove certain functionality and also have behavior change. While they try to keep plugin API somehow compatible to now screw too much over plugin devs, its still not the same thing.

Instead we decided with Sven to have a shared virtual provides 'vim-plugin-runtime' that both packages provide and plugins can depend on. This is a quite KISS solution while still not be technically wrong about neovim providing vim.

Since this is now fixed from the vim/neovim side, we should be able to rebuild packages which support both, right?

Does anyone have a list of packages they know work well with both neovim and vim, which should be switched?

@Eli
I checked all packages in vim-plugins group.

Work with both vim & neovim:
vim-airline{,-themes}
vim-ale
vim-align
vim-ansible
vim-bufexplorer
vim-coverage-highlight
vim-csound
vim-ctrlp
vim-easymotion
vim-editorconfig
vim-fugitive
vim-gitgutter
vim-grammalecte
vim-indent-object
vim-jad
vim-jedi
vim-molokai
vim-nerdcommenter
vim-nerdtree
vim-seti
vim-supertab
vim-surround
vim-syntastic
vim-tabularize
vim-tagbar
vim-ultisnips
vim-vital

Works only in vim:
vim-latexsuite

Doesn't seem to work at all (?):
vim-pastie


There is also another issue - vim has a pacman hook that updates help tags for installed plugins. If using plugins with neovim (without vim installed) is going to be officially supported, maybe a similar hook should be added to neovim? That would potentially update help tags twice but it shouldn't be an issue.

Edit:
vim-spell-* dictionaries work fine with neovim as well.

Is there further progress? It seems that the current plan is a todo list for rebuilding vim-* plugins to depend on vim-plugin-runtime instead of vim if applicable. If that sounds good, I can help on creating a todo list with the following description.

```
This is a TODO list to allow using vim-* plugin packages with community/neovim without installing extra/vim. To achieve that, vim-* plugin packages should depend on the virtual package vim-plugin-runtime instead of vim [1]. Please check whether a plugin works with both vim and neovim or not, and update depends= in PKGBUILD and rebuild if applicable. If a plugin works with vim but not neovim, the corresponding package can be marked as finished without any change. Updated packages can go directly to stable repositories.

[1] https://bugs.archlinux.org/task/41453
```