Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#71404 - [neovim] vim plugins and runtimepath ordering

Attached to Project: Community Packages
Opened by brisvag (brisvag) - Wednesday, 30 June 2021, 13:50 GMT
Last edited by Daniel M. Capella (polyzen) - Sunday, 16 July 2023, 06:44 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Caleb Maclennan (alerque)
Daniel M. Capella (polyzen)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This is somewhat related to the other neovim bug report currently open (, but no strictly the same.

`vim` and `neovim` plugins are supposed to be largely compatible, which is why `/usr/share/vim/vimfiles` is appended to the end of the runtime path by the current neovim `pkgbuild`.

However, since this directory only contains plugin-related files, I would think that this should appear in the runtime path *before* `/usr/share/nvim/runtime`. Is there a reason why this is not the case?

I recently encountered this issue (, which seems to be caused by this ordering problem, and is likely to appear with any other package that overrides a file that `nvim` also ships. It would be better to solve this at this level, rather than forcing the existence of duplicate plugins for `vim` and `neovim` or having people edit their runtimepath manually.
This task depends upon

Closed by  Daniel M. Capella (polyzen)
Sunday, 16 July 2023, 06:44 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Seems the ordering was deemed appropriate. Please open another issue regarding neo/vim plugin specific locations if that is still wanted.
Comment by Sven-Hendrik Haase (Svenstaro) - Thursday, 30 September 2021, 00:42 GMT
Hey Caleb, any opinions on this?
Comment by Caleb Maclennan (alerque) - Thursday, 30 September 2021, 08:27 GMT
At first blush, I don't think the solution proposed here is viable but I do agree there is a problem. Also looking at  FS#65616  here, a few random comments:

* Neovim is not a drop in replacement for vim. It can't be assumed to be so.
* Plugins that work for vim overwhelmingly also work for neovim.
* The reverse is not true, many plugins are neovim specific and won't work in plain vim.

Hence including the vim rtp before neovim's own distribution files is a really bad idea, plugins may be trying to fixup something in vim that does not need fixing up in neovim.

I would propose a further split: have vim & neovim specific plugin locations. Have vim only look at the former by default (plugins, then itself). Have neovim look at both, but in a different order (it's own plugins, then itself, then vim plugins).

Packages that provide neovim plugins could put them where vim wouldn't be tempted to trip over them, while still being first priority in the rtp for neovim.
Comment by Sven-Hendrik Haase (Svenstaro) - Thursday, 30 September 2021, 15:34 GMT
I don't have strong opinions on this and I'm also not knowledgeable about this so feel free to do what seems correct to do.