Arch Linux

/usr/share/vim/vimfiles/ is not in the default neovim runtimepath because not all plugins automatically work with both, and /usr/share/vim/vimfiles belongs to the vim package.

Though I do note that our neovim packaging apparently does manually add it to the runtimepath anyway... if we're packaging it with the intent to make it a drop-in replacement for vim, then shouldn't it also provide vim?

Either way, the package really should either depend on vim as it currently does, or depend on something that is provided by both vim and neovim.

neovim should not provide vim as long as we do correct things, because neovim is not a compatible vim drop in replacement and incompatible on many things.
However in general vim plugins mostly try to do things in a way that makes them compatible with both.
The request here is not about vim-ale but about neovim and what to do with it in general

Hence my confusion. :D

Does it truly make sense to have neovim by default load all /usr/share/vimfiles plugins? If so, does it make sense to have, at least, some common provides?

I dont fully understand what we are trying to solve here from a user story point of view, having 10MB less installed? or fixing depends of plugins that don't work with neovim?
Is there actually any plugin we know of that doesn't work and won't ever work with neovim? afaik, they all do.

I agree neovim should not provide vim, it is not a drop in replacement from the CLI for many/most scenarios. It is however roughly capable of loading any plain vim plugins. Since we can't have our cake and eat it to I think the only way to resolve this will be with a virtual package. Both vim and neovim can provide something (say `vim-editor`). Any packages that directly *call* vim as a command should depend on vim. Plugins that only get loaded in/by vim can depend on `vim-editor` (or whatever it is). That way neovim can avoid providing something it doesn't actually offer while not forcing the vim package on anybody installing plugin packages.

See also my comment at  FS#71404 .

@Caleb: Thats what vim-plugin-runtime is for nowadays: https://github.com/archlinux/svntogit-community/blob/packages/vim-nerdtree/trunk/PKGBUILD#L15

@anthraxx That sounds about right, and it's provided by both `vim` and `neovim`.

So the upshot is the only thing needed to close this issue is make the [community]/vim-ale package depend on `vim-plugin-runtime` instead of `vim`?

@Caleb: Well a better shot would be a todo list and fix all the plugins instead of case by case :) I can probably setup a todo in the evening.

With that understanding I'm on this! @anthraxx its your package but I just adopted and will fix this (assuming you don't mind based on previous IRC chat).

Re the tangentially related RTP issues in comments, those are better covered in  FS#71404 .

Sure a todo list that takes care of this for all plugins sounds good too.

The initial report is fixed in vim-ale-3.1.0-2

I'm leaving this issue open for now just until there is a todo list opened so we don't forget.

The todo list has been made and treated: https://archlinux.org/todo/make-vim-plugins-depend-on-vim-plugin-runtime-so-neovim-or-vim-can-be-used/

This issue can now be closed :)