Packer.nvim: rtp without initial seperator

[AckslD]

If I want to specify a subdirectory as mentioned in the README, e.g. vim then I need to set this to rtp = "/vim". Maybe the / should be added automatically?

EDIT: In fact there seems to be an issue since if I set rtp = "vim" then I get

    path = "/home/axel/.local/share/nvim/site/pack/packer/start/himalayavim"

but

vim.o.runtimepath = vim.o.runtimepath .. ",/home/axel/.local/share/nvim/site/pack/packer/start/himalaya/vim"

however if I set `rtp = "/vim" I get:

    path = "/home/axel/.local/share/nvim/site/pack/packer/start/himalaya/vim"

but

vim.o.runtimepath = vim.o.runtimepath .. ",/home/axel/.local/share/nvim/site/pack/packer/start/himalaya//vim"

i.e. in neither case I get what I want.

[akinsho]

@AckslD where is the second example of

vim.o.runtimepath = vim.o.runtimepath .. ",/home/axel/.local/share/nvim/site/pack/packer/start/himalaya/vim"

coming from? is the path the path set in packer for that plugin and but the o.runtimepath is incorrect. Does it work in the case where you set /vim or does it fail because the rtp is broken?

[AckslD]

@akinsho It comes from ~/.config/nvim/plugin/packer_compiled.vim, so to me it seems the rtp-argument is broken.

[akinsho]

Hmm just glancing at the logic it seems like a separator should be being added but maybe isn't not sure why or how though

[akinsho]

Okay I actually found the bug. The point where we should be appending the rtp path for the plugin we aren't actually using a correctly joined path. I've fixed it locally but strangely enough the plugin himalaya is still not showing up i.e. it's command etc aren't available

[akinsho]

@AckslD I've raised a PR which fixes the path concatenation but can't get Himalaya to actually load. Not sure what's going on exactly or if packer needs to do something else. @wbthomason not sure if you're around +/- know the answer, might we have to trigger something to get vim to pickup files after updating the rtp. I can see the directory is now added but don't think that's enough to load the plugin.

[AckslD]

Thanks @akinsho! I also noticed that the commands where not loaded even when I manually fixed packer_compiled. However calling the functions in autoload does work.

[wbthomason]

Thanks, @akinsho! I'll take a look at the PR in a sec. Yes, we'll also need to add something to source files in plugin/ etc. at the updated rtp - I'm not sure if there's an easy built-in way to do this, or if it's better to generate the list of relevant files and source them in packer_compiled ourselves. I might have to ask around on the Gitter for advice about the "right" way to do that.

[akinsho]

@wbthomason 👍🏿 I dug around vim-plug a bit to try and see how it handles an rtp argument but I really find it hard to follow all that vimscript. Seems though that most things end in a manual source command, but I wouldn't be surprised if there was a specific method by which manipulating the &rtp automagically did the desired thing. Kind of curious if vim.o.runtimepath = vim.o.runtimepath + <new-value> works the same as something like set rtp+=<value> etc.

Side note: should there be a separate issue to track the fact that plugins with an rtp argument aren't sourced correctly. Or could re-open and rename this one 🤷🏿

[akinsho]

@wbthomason think I've figured this out. So the TLDR is that packer manipulates the &rtp too late, it goes back to the age old doing things in the plugin/packer_compiled.vim vs in the init.lua conversation. In this specific case I believe vim checks the rtp after loading the vimrc/init.lua and then sources the files in the rtp. But things things that happen after like in plugin/*.vim won't get the same treatment.

I tested this in this case by adding set rtp+=<path-to>/himalaya/vim/ which loads the plugin as expected, whereas it doesn't work when the rtp is set later