Change:
Using vim-configurable to bake plugins into a system-wide vim configuration, there doesn't appear to be a way to make a plugin's syntax files precede those in $VIMRUNTIME. Since most syntax files contain a guard-clause to avoid clobbering any previously-set syntax, such plugins can't have the desired effect. I'm using Vim 8 packages to bake haskell-vim (plus some other plugins) into my system-wide vim configuration. I have an that contains: The haskell-vim plugin contains a syntax file. A less feature-rich syntax file also exists at $ Both files begin with a guard-clause: and end with so whichever runs first wins. I want to use haskell-vim's syntax file, but the way vim_configurable works, I end up with a runtimepath like: I'm trying to figure out how I could bump this particular plugin to an earlier position in runtimepath, whether it makes sense to bump the whole package (all plugins), or whether there's some other solution.
I found a way to work around this. I a symlink to the relevant syntax file in my user vim config: This works because is earlier in Vims runtimepath than $VIMRUNTIME is. I was mystified for a while as to why was empty despite all the plugins I've baked into my Vim derivation, but finally realized they only show up there if they're listed in . I previously had no need to include them in that list. Now, I've the haskell-vim plugin to and everything works.
I encountered the same problem. As far as I understand the situation, this is a bug (edit: in vim8/neovim's handling of packpath? see further below). Specifically, vim- in nixpkgs currently contains : where means user plugins are appended at the end of packpath. I checked the code of one of the top "classical" Vim plugin managers — Vundle — and it prepends the user plugins at the beginning of rtp, with operator, : (Only the explicitly named subdirectories of the plugins are appended to the list with ; the default action is to prepend with .) The behavior of Vundle also matches the semantics of the default value of rtp (a.k.a. runtimepath) on Unix as specified : I was hit by this problem when trying to load the plugin into . Unforutnately, its filetype plugin fails to load (disabling many important features of vim-go), because the file from $VIMRUNTIME is earlier in runtime path than vim-go's one, as a result of the above bug in vim_customizable a.k.a. vim- EDIT: After some more digging, I believe this is actually just how neovim (and vim8?) behaves. I don't understand why it's so. I forked nixpkgs and changed the snippet to: but the plugin directories are still appended at the end of , which makes them problematic to use for syntax and/or ftplugin functionality. My current workaround is to add the following string at the beginning of my .vimrc:
workaround works for me, I got caught by this when my python-mode vim plugin wasn't working here is my config, which works file:
I created the issue , which I now realize is a duplicate. I also created a report upstream, which may be interesting for the people here. If you have any additional info, please add it there:
I followed workaround as per example, but I kept getting errors about duplicate entries in the runtimepath. The fix is to not set (it's unnecessary now anyway, as all we're building the runtimepath ourselves instead of relying on it to generate packpath).
The problem here is that the default runtimepath . Vim does appear to respect the order in packpath, but this doesn't matter because the paths will be appended to a runtimepath that is already non-empty. This is not a bug in vim (or neovim) as far as I'm concerned. The good news is that directories can be included in the default runtimepath before : either via or (and via , of course). is not set by default, but can be during compile-time using the option. In any case, the code would no longer be needed in the vimrc. I don't know if there's a clean way to do this if the interface is to be preserved. I managed to get things working with the option, but the code is ugly. I basically modified the configure function to first call before calling itself again with the result. I don't know how you would implement the 'vimfiles' approach; you would want to create a symlink in the original vimconfigurable output path, but how? Ultimately, I think breaking changes need to be made if we want clean code. P.S. I believe this is also the cause of LnL7/vim-nix, to mentioned another issue.
What do traditional plugin managers like vim-plug differently then?
I'm not too familiar with the internals of these package managers, but, looking at vim-plug, it does quite a bit to ensure that the user-specified plugins are loaded correctly. The take-away is that it's modifying the runtimepath directly. If you want to go that route, akavel's solution () is nice and simple.
As far as I can tell, the fix only applied to vim proper, not neovim. Should that be a separate issue or can we re-open this? (Or am I holding it wrong?)

Discussion:
); in '' <del> set packpath-=~/.vim/after set packpath+=${packDir packages} set packpath+=~/.vim/after </del> <ins> set packpath^=${packDir packages} set runtimepath^=${packDir packages} </ins> filetype indent plugin on | syn on '');