Packer.nvim: nvim-compe in opt dir, not work

[hamsterBiscuit]

https://user-images.githubusercontent.com/19209958/107872044-48531200-6ee2-11eb-8d46-e72ba6bced29.mp4

see this video.

I use packadd to use it ,but is not work

and hrsh7th comment

we should deal with this situation

or I do something can lazy it and worked?

[wbthomason]

Ah. This is an upstream issue I've run into in #93. I think the easiest fix (short of patching Neovim, which may be the right fix) is to add an explicit sourcing step for after directories.

[wbthomason]

@hamsterBiscuit: Could you please test the PR in #215 and see if it fixes this issue for you?

[hamsterBiscuit]

yep, it fixed, and worked for me
thanks for this.

[hamsterBiscuit]

and I test lazy load mattn/emmet-vim,and it not work
I find the reason, Doesn't seem to be related to this

code

  use {
    "mattn/emmet-vim",
    ft = {"html", "css", "javascript", "javascriptreact", "vue", "typescript", "typescriptreact"},
    config = [[require("plugin-config.emmet")]]
  }

if it in start dir ,it is worked. Sad.

[wbthomason]

Sorry, what is the reason you found?

[hamsterBiscuit]

Sorry，for emmet, I not find reason......my bad english.....

[wbthomason]

Ah, no worries. Looking at the code of that plugin, I would guess it has to do with the plugin's initialization only being triggered on the Syntax * autocmd. I'm not sure that this autocmd gets triggered after FileType if you have set syntax=on...

If you lazy-load emmett, what about it doesn't work? Does the EmmetInstall command exist after opening the right kind of file?

[hamsterBiscuit]

a,
if in html
the set syntax output syntax=html.
and EmmetInstall command exist.
but it is not worked

[wbthomason]

Running EmmetInstall doesn't work? How does it fail?

[hamsterBiscuit]

no message.
but Emmet command worked

[hamsterBiscuit]

maybe config load later than plugin...
that is reason
I test later

[wbthomason]

The config key does run after the plugin, and that could cause this. If you need to set variables before the plugin loads, use the setup key.

[hamsterBiscuit]

thanks, now it is works,
my emmet config:

  use {
    "mattn/emmet-vim",
    ft = {"html", "css", "javascript", "javascriptreact", "vue", "typescript", "typescriptreact"},
    setup = [[require("plugin-config.emmet")]],
    config = function()
      vim.api.nvim_command(
        [[autocmd FileType html,css,javascript,javascriptreact,vue,typescript,typescriptreact EmmetInstall]]
      )
    end
  }

user_emmet_leader_key in config function is not work, in setup function is worked.

thanks again.

[akinsho]

Hmm I actually can't get this to work in the opt dir 🤔 I'm using

    use {
      "hrsh7th/nvim-compe",
      event = "InsertEnter *",
      disable = is_work,
      config = require("as.plugins.compe"),
      requires = {{"tzachar/compe-tabnine", run = "./install.sh"}}
    }

and nothing happens on insert enter, with the most up to date packer version

[wbthomason]

Interesting. You don't start getting completions? is_work is false?

For reference, I'm using

use {'hrsh7th/nvim-compe', config = [[require('config.compe')]], event = 'InsertEnter *'}
use {'hrsh7th/vim-vsnip', config = [[require('config.vsnip')]], event = 'InsertEnter *'}

which has worked for me with latest Packer across multiple computers.

Dumb question: you already recompiled, I assume?

[akinsho]

Yep is_work is true and compiled output includes

vim.cmd [[au InsertEnter * ++once lua require("packer.load")({'nvim-compe'}, { event = "InsertEnter *" }, _G.packer_plugins)]]

just removing the event works 🤔 I'll see if I'm missing something somewhere

[wbthomason]

Yep is_work is true

I assume you mean false, so that the plugin isn't disabled?

just removing the event works

Hmm, so it's definitely the lazy-loading not working. What's your version of nvim-compe? Also, just to check, your compiled file has a long list of paths for the value of after_files in the packer_plugins table for nvim-compe?

[akinsho]

@wbthomason sorry yeah mean it's false, the output from the packer plugins table is

{
  after_files = { "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_buffer.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/
after/plugin/compe_calc.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_nvim_lsp.vim", "/home/akin/.local/share/nvim/site/pack/packer/o
pt/nvim-compe/after/plugin/compe_nvim_lua.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_omni.vim", "/home/akin/.local/share/nvim/site
/pack/packer/opt/nvim-compe/after/plugin/compe_path.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_snippets_nvim.vim", "/home/akin/.lo
cal/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_spell.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_tags.vim", "/ho
me/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_treesitter.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe
_ultisnips.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_vim_lsc.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/
after/plugin/compe_vim_lsp.vim", "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin/compe_vsnip.vim" },
  config = { "\27LJ\2\2<b3>\5\0\0\a\0\30\0B6\0\0\0'\1\1\0B\0\2\0029\0\2\0005\1\b\0005\2\3\0005\3\4\0=\3\5\0025\3\6\0=\3\a\2=\2\t\1B\0\2\0016\0\n\0009\0\v\0005\1\f\0006\2\r\00
09\2\14\2+\3\2\0=\3\15\0026\2\r\0009\2\16\0029\2\17\2B\2\1\1\18\2\0\0'\3\18\0'\4\19\0'\5\20\0\18\6\1\0B\2\5\1\18\2\0\0'\3\18\0'\4\21\0'\5\22\0\18\6\1\0B\2\5\1\18\2\0\0'\3\18\
0'\4\23\0'\5\24\0\18\6\1\0B\2\5\1\18\2\0\0'\3\18\0'\4\25\0'\5\26\0\18\6\1\0B\2\5\1\18\2\0\0'\3\27\0'\4\25\0'\5\26\0\18\6\1\0B\2\5\1\18\2\0\0'\3\18\0'\4\28\0'\5\29\0\18\6\1\0B
\2\5\1\18\2\0\0'\3\27\0'\4\28\0'\5\29\0\18\6\1\0B\2\5\1K\0\1\0\29v:lua.__s_tab_complete()\f<S-Tab>\6s\27v:lua.__tab_complete()\n<Tab>\25compe#close('<C-e>')\n<C-e>1compe#conf
irm(lexima#expand('<LT>CR>', 'i'))\t<CR>\21compe#complete()\14<C-Space>\6i\29lexima#set_default_rules\afn\28lexima_no_default_rules\6g\bvim\1\0\3\texpr\2\vsilent\2\fnoremap\2
\bmap\ras_utils\vsource\1\0\0\nvsnip\1\0\2\tkind\16 [Vsnip]\rpriority\3<dc>\v\vbuffer\1\0\1\tkind\17 [Buffer]\1\0\6\rnvim_lsp\2\rnvim_lua\2\nspell\2\ftabnine\2\15treesitter
\2\tpath\2\nsetup\ncompe\frequire\0" },
  loaded = true,
  needs_bufread = false,
  path = "/home/akin/.local/share/nvim/site/pack/packer/opt/nvim-compe"
}

[akinsho]

nvim-compe version is 3ce7f98 Mon Feb 15 18:42:33 2021 +0900 hrsh7th (grafted, HEAD -> master, origin/master, origin/HEAD) Remove flicker

[wbthomason]

Fascinating. That looks exactly right, and works on my system/seems to have worked for @hamsterBiscuit. compe version matches too...

[akinsho]

Hmm just tried a few different things, e.g. clean install, checking the plugin can be required (it can), using a simple config, disabling the required plugins etc. and no luck 🤔 I wonder what it does with the after directory since I have quite a few after files

EDIT: They wouldn't relate at all it just has plugin files it sources in after/plugin, will try whittling away at my config to see if I can find a cause

[wbthomason]

The after directory list is because compe sets up most of its built-in sources as part of sourcing after/plugin. Since packadd does not source files in this directory (see the issue linked in the compe issue @hamsterBiscuit linked to start this issue), I added manual sourcing of these files to packer in #215, which fixed this issue for me. Basically, when the lazy-load for a plugin is triggered, packer iterates through after_files (if any) and loads them.

[akinsho]

I read through that issue at the time, was keen to add lazy loading for it since it's a little expensive to load upfront, not sure what's going on on my end could be something weird in my setup somewhere

[wbthomason]

Looking at your config, I'm not seeing anything too strange (as a side note, I may have to steal your __tab_complete and __s_tab_complete functions for my own setup; I've been too lazy to get tab working properly with vsnip and compe).

I would suggest trying two things: first, add a print to your compe config function so that we can be sure it's getting invoked properly on InsertEnter. Second, try adding an echom or two to some of the files in ~/.local/share/nvim/site/pack/packer/opt/nvim-compe/after/plugin, to make sure those are getting sourced appropriately.

If both of those print as expected......maybe there's a weird interaction with tzachar/compe-tabnine, just because it's one of the differences between our setups?

[akinsho]

@wbthomason so just tried what you suggested, initially I found that tzachar/compe-tabnine was in my start dir not my opt so interestingly that had it's after/plugin sourced. I removed it and disabled that key in compe. I then added a log to my config which does print on insert enter. I added some logs then to after/plugin/compe_buffer.vim in the plugin dir as well as in the after/plugin/compe_nvim_lsp.vim, neither of the messages print though

[wbthomason]

Yeah - the weird thing with native packages is that after/plugin gets sourced as expected for start plugins, but not opt (and this is apparently by design...)

The result you report (i.e. InsertEnter runs the config as expected, but after isn't sourced) is confusing to me. Again, just double-checking (since you already checked your packer version), you have these lines, in lua/packer/load.lua, right?
https://github.com/wbthomason/packer.nvim/blob/115271e5143c5e2e4e763959b3d49361366e6241/lua/packer/load.lua#L29-L32

[wbthomason]

Also, given https://github.com/akinsho/dotfiles/blob/d1c83880dcd26bb987b3279fa9d74a3c16c53d43/.config/nvim/lua/as/plugins/init.lua#L88-L89, is there a chance that your packer version on this machine is your development fork that may not have the latest commits?

[akinsho]

Ok finally managed to figure it out but no clear idea what actually happened 😅 . So I have

    use {"wbthomason/packer.nvim", opt = true, cond = not_developing}
    use_local {"contributing/packer.nvim", opt = true, as = "local-packer", cond = developing}

when I work on a local version of packer stuff so both packages are installed but one is aliased as local and should not be loaded if I don't have a particular environment variable set. Unfortunately there seems to be some unexpected overlap. It isn't actually loading my dev for since I actually have a print statement in that plugin so I know when it's loaded, but maybe some of it's files overlap somehow

[akinsho]

Sorry for the confusion @wbthomason, really not sure why they are interfering with each other, I'm pretty sure it isn't loading the dev fork since that prints a big warning, anyway turning it off does seem to work

[wbthomason]

Ah - so, I'm pretty sure this has to do with how require works. Even though your dev version of packer is aliased, its lua directory still gets added to the package.path list - and that doesn't get the alias applied. So, it can happen that Lua finds the packer files in local-packer/lua/packer* rather than in packer.nvim/lua/packer*.

[wbthomason]

Regardless, I'm glad things are working now! It is very nice to be able to lazy-load compe; the startup cost of that one is not trivial.