Packer.nvim: Plugin functions not available in init.vim

[clason]

I have a problem where functions provided by plugins loaded via packer are not available from init.vim.

For example,

1. nvim-lsp seems not to be loaded by the time that it's required in my lua/lsp.lua, which itself is required in my init.vim:

E5108: Error executing lua /Users/clason/.config/nvim/lua/lsp.lua:18: module 'nvim_lsp' not found:

This might be a problem with packages and lua in general, though.

1. vimtex provides a function vimtex#toc#new, which I use to define customized tables of contents via a CreateTocs() vimscript function that is defined in my init.vim and then called as a file type autocommand for tex:

Error detected while processing function CreateTocs[1]..vimtex#toc#new:
line    1:
E121: Undefined variable: g:vimtex_toc_config
E116: Invalid arguments for function deepcopy
E116: Invalid arguments for function vimtex#util#extend_recursive
E116: Invalid arguments for function extend
E15: Invalid expression: extend( deepcopy(s:toc), vimtex#util#extend_recursive(   deepcopy(g:vimtex_toc_config
),   a:0 > 0 ? a:1 : {}))

My init.vim basically looks like

lua plugins = require('plugins') " lua/plugins.lua follows the readme and just calls use 'PLUGIN' without options
...
function CreateTocs()
  let g:toc_label = vimtex#toc#new({
        \ 'layers' : ['label'],
        \ 'show_help' : 0,
        \ 'show_numbers' : 0,
        \})
endfunction
au Filetype tex call CreateTocs()
...
lua require 'lsp' " lua/lsp.lua requires 'nvim_lsp' and does the usual server setup and on_attach config

I see from your dotfiles that these plugins are working for you -- what am I doing wrong?

[wbthomason]

Strange - could you share your plugins.lua with me? If you aren't using any lazy-loaders, then I suspect this is an issue with getting the plugins actually installed. Have you called packer.init() before any packer.use() calls in your plugins.lua?

[clason]

Sure! Here's my plugins.lua

local packer = nil
local function init()
  if packer == nil then
    packer = require('packer')
    packer.init()
  end
  local use = packer.use

  packer.reset()

  use 'wbthomason/packer.nvim'

  use 'lervag/vimtex'
  use 'JuliaEditorSupport/julia-vim'
  use 'SirVer/ultisnips'
  use {'honza/vim-snippets', after = 'ultisnips'}
  use {'rbonvall/snipmate-snippets-bib', after = 'ultisnips'}
  use 'junegunn/vim-easy-align'
  use 'tpope/vim-commentary'
  use 'tpope/vim-surround'
  use 'tpope/vim-repeat'
  use 'tpope/vim-fugitive'
  use 'mhinz/vim-signify'
  use 'itchyny/lightline.vim'
  use 'neovim/nvim-lsp'
  use {'haorenW1025/completion-nvim', after = 'nvim-lsp'}
  use 'cocopon/iceberg.vim'
end

local plugins = setmetatable({}, {
  __index = function(_, key)
    init()
    return packer[key]
  end
})

return plugins

No lazy-loading (apart from that by the plugins themselves). From init.vim, I just lua plugins = require 'plugins'. The plugins are there (for example, :VimtexCompile works), but I can't use their functions in my init.vim.

[wbthomason]

As one minor note, you will need to call packer.compile(<SOME PATH ON RTP>) to make sure your after loads work - sequencing implies lazy-loading since non-opt packages can't be manually loaded in a guaranteed sequence. That wouldn't cause the bug you're seeing, though.

I'll try to reproduce this on my end. Thanks for the report!

[clason]

As one minor note, you will need to call packer.compile() to make sure your after loads work - sequencing implies lazy-loading since non-opt packages can't be manually loaded in a guaranteed sequence. That wouldn't cause the bug you're seeing, though.

Ah, makes sense . What's the benefit of compiling, by the way?

I'll try to reproduce this on my end. Thanks for the report!

Thanks for the plugin!

[wbthomason]

Ah, one other question - since you shouldn't actually need to require plugins in your init.vim, I'm wondering if you've run require('plugins').install()?

[clason]

Yes, the plugins are installed (and working -- sorry for the sneak edit to the comment!)

(I'm using require to load lua functions from .config/nvim/lua/, since that was the most robust way I could find. Here I'm defining a lua plugins.update() mapping afterwards.)

[wbthomason]

Ah, makes sense . What's the benefit of compiling, by the way?

The idea is that by compiling lazy-loaders, you can get faster startup by not needing to load packer unless you're explicitly performing plugin management operations, without losing the benefits of lazy-loading.

Typically, plugin managers like vim-plug generate the logic for lazy-loading at startup, but (in my experience) that imposes a nontrivial startup time cost. Typically (again, just in my experiments) it's faster to load the generated loader file than it is to load packer and generate and run all the lazy-load logic.

[clason]

Interesting. So how would this work with the example setup above?

[wbthomason]

For your config, the generated code will be pretty simple - it'll basically be (other than a function that is used to perform more complex loads) just the lines:

packadd vim-snippets
packadd snipmate-snippets-bib
packadd completion-nvim

which (when you call plugins.compile(<SOME FILE>)) will be put in <SOME FILE> and can be loaded during your startup.

For a more complicated example, you can see the file packer generates for me: https://github.com/wbthomason/dotfiles/blob/linux/neovim/.config/nvim/plugin/packer_load.vim

[clason]

For a more complicated example, you can see the file packer generates for me: https://github.com/wbthomason/dotfiles/blob/linux/neovim/.config/nvim/plugin/packer_load.vim

Whoa! :)

I'll remove the after, then, since that's not what I actually need in this case. Simpler is better!

[wbthomason]

Per your original issue: I can replicate the behavior with vimtex on my end, but it seems to be because the variable g:vimtex_toc_config isn't defined - the function exists and is available.

Looking through the vimtex code, this variable should be created by vimtex#init(), which should be called in ftplugin/tex.vim. Manually calling vimtex#init() at the start of your CreateTocs function does fix the error for me, but it's interesting that it's not running in the ftplugin first.

It seems like the Filetype tex autocommand is firing before the ftplugin is sourced? Do you have an example of this working without error with another plugin manager?

[clason]

Yes, this works fine with vim-plug. I can also manually require 'lsp' after starting nvim (with packer-nvim) and get everything working; it's just that it doesn't work from init.vim. I've tried adding a sleep after the plugin loading, but that doesn't help.

This might actually be an issue with nvim's handling of packages -- let me check what happens in vim.

[wbthomason]

The nvim_lsp issue seems to be that ~/.local/share/nvim/site/pack/... is not on the Lua package.path during init. That seems like a Neovim issue (from the docs: "When Vim starts up, after processing your .vimrc, it scans all directories in
'packpath' for plugins under the "pack/*/start" directory. First all those
directories are added to 'runtimepath'. Then all the plugins are loaded."), as I would expect directories to be added to package.path during the startup packpath scan.

I suspect this works with vim-plug because it is not using the native packages feature.

[clason]

You are right, this is not an issue with packer, I realize this (only) now. Sorry! It seems that packages just don't play nice with a purely vimrc configuration...

How are you doing this? I couldn't quite work it out from your dot files...

Would putting everything in opt and explicitly loading it via packloadall help?

[wbthomason]

You are right, this is not an issue with packer, I realize this (only) now. Sorry! It seems that packages just don't play nice with a purely vimrc configuration...

No worries - I'm going to see if I can put together a Neovim PR to fix this, since the behavior is unintuitive.

How are you doing this? I couldn't quite work it out from your dot files...

I'm not 100% sure why what I'm doing works whereas this approach does not, but: I tend to put all my plugin configuration/custom function definitions/autocommand definitions in plugin/<plugin_name>.vim and/or autoload/<plugin_name>.vim.

Doing this with your vimtex example works for me without needing to explicitly call vimtex#init(), which seems to indicate that there's aa weird timing/sequencing issue between the sourcing of plugin/ files and the sourcing of ftplugin/ files in packages.

For nvim-lsp, I lazy-load that plugin (and completion-nvim, etc.) on InsertEnter to reduce startup time (I've found that sourcing significant Lua plugins adds a lot of time to startup).

Would putting everything in opt and explicitly loading it via packloadall help?

Yeah, this would work - if I can't get this fixed via PR reasonably quickly, I might move packer to take this approach.

[clason]

Would putting everything in opt and explicitly loading it via packloadall help?
Yeah, this would work - if I can't get this fixed via PR reasonably quickly, I might move packer to take this approach.

Not from init.vim, it seems. This might be a neovim issue that init.vim is loaded at a different time than .vimrc in the packpath sequence?

(To be precise: packloadall doesn't work, but packadd nvim-lsp and packadd completion-nvim does -- however, packadd vimtex still fails.)

For nvim-lsp, I lazy-load that plugin (and completion-nvim, etc.) on InsertEnter to reduce startup time (I've found that sourcing significant Lua plugins adds a lot of time to startup).

Interesting, I'll check that out (but won't then hover and definition etc. not work until you've typed something?)

[wbthomason]

Not from init.vim, it seems. This might be a neovim issue that init.vim is loaded at a different time than .vimrc in the packpath sequence?

To clarify, making everything opt and using packaddall doesn't work if you do packaddall in init.vim? If so, fascinating - that does seem like a bug/unexpected behavior with regards to init.vim and packages...

Interesting, I'll check that out (but won't then hover and definition etc. not work until you've typed something?)

Yeah, it's definitely not perfect. A feature I've planned for packer (but haven't had time to implement yet) is time-based deferred loading (inspired by things Emacs and VS Code provide). This would let me load things before e.g. InsertEnter but after the first screen draw, to keep startup time low but get things like hover, etc. working before starting to type.

[clason]

To clarify, making everything opt and using packaddall doesn't work if you do packaddall in init.vim? If so, fascinating - that does seem like a bug/unexpected behavior with regards to init.vim and packages...

Actually, it's a little more complicated -- there's packadd for loading one package from opt, and packloadall for loading all packages from start -- for whatever reasons this is not symmetric. This works to get nvim-lsp working, but not for vimtex. Moving those TOC functions to a filetype plugin would be an acceptable workaround, though. (I don't like scattering my configuration over too many files, but it seems This Is The Way...)

[clason]

For nvim-lsp, I lazy-load that plugin (and completion-nvim, etc.) on InsertEnter to reduce startup time (I've found that sourcing significant Lua plugins adds a lot of time to startup).

You're right, it seems that nvim-lsp takes significantly longer to load as a package. Strange:

019.513  007.281  007.281: sourcing /Users/clason/.local/share/nvim/site/pack/packer/start/nvim-lsp/plugin/nvim_lsp.vim

vs. vim-plug

053.471  000.309  000.309: sourcing /Users/clason/.local/share/nvim/plugins/nvim-lsp/plugin/nvim_lsp.vim

(the order of loading is different; I'm just comparing self-time).

[wbthomason]

Right, that about matches what I've seen. I have no idea why that's the case - from the docs, my understanding of the packages feature was that it should be more or less equivalent to "normal" plugins for start packages. I'm poking around the neovim source to see if I can figure out what's different...

[clason]

It seems better as an optional plugin, by the way: if I mark it as opt = true and packadd! it explicitly (and same for completion-nvim), I see

032.126  000.325  000.325: sourcing /Users/clason/.local/share/nvim/site/pack/packer/opt/nvim-lsp/plugin/nvim_lsp.vim

Another thought I had was to (ab)use the setup key to require the lsp setup after loading nvim-lsp, but that never seems to be called (server is not configured)?

(Weird that there's no packaddall... probably defeats the purpose.)

[clason]

Oh, and for reference (third paragraph):

:packl[oadall][!]       Load all packages in the "start" directory under each
                        entry in 'packpath'.

                        First all the directories found are added to
                        'runtimepath', then the plugins found in the
                        directories are sourced.  This allows for a plugin to
                        depend on something of another plugin, e.g. an
                        "autoload" directory.  See packload-two-steps for
                        how this can be useful.

                        This is normally done automatically during startup,
                        after loading your .vimrc file.  With this command it
                        can be done earlier.

                        Packages will be loaded only once.  Using
                        :packloadall a second time will have no effect.
                        When the optional ! is added this command will load
                        packages even when done before.

                        Note that when using :packloadall in the vimrc
                        file, the 'runtimepath' option is updated, and later
                        all plugins in 'runtimepath' will be loaded, which
                        means they are loaded again.  Plugins are expected to
                        handle that.

Maybe worth pointing out in the readme?

[wbthomason]

Another thought I had was to (ab)use the setup key to require the lsp setup after loading nvim-lsp, but that never seems to be called (server is not configured)?

When you tried this, did you run plugins.compile? setup won't be called unless you've compiled lazy-loaders, but works for me when I do that.

I should really make the compilation process less manual; maybe adding a config key for a compile output file that, if present, will cause compilation to run automatically after install/update/sync.

[clason]

Or at least a bit of documentation :) (I did not.)

Could you walk me through this? When do I compile, where should I put the result, and how should I use it?

[wbthomason]

Or at least a bit of documentation

Well, that's embarrassing... I thought I had documented that. I'll add some docs to the README.

compile takes a path and saves its output to that path. The path should be on your rtp, and have vim as its extension.

For a concrete example, I use plugins.compile('~/.config/nvim/plugin/packer_load.vim'). Then, during startup, packer_load.vim gets sourced (because ~/.config/nvim/plugin is on rtp), and handles lazy-loaders, setup, etc.

[clason]

OK, that works! But it adds 0.010 self-time to startup...

[wbthomason]

0.010 as compared to which alternative - vim-plug, marking as opt and manually packadd'ing, etc.?

[clason]

marking as opt and manually packadding.

(not complaining, just reporting :))

[wbthomason]

Still, that's undesirable. In the manual packadd version, you were requiring the same LSP setup code (i.e. the additional cost is not just due to running that setup code?)

[clason]

yes, the difference is between

packadd! nvim-lsp
packadd! completion-nvim
require 'lsp'

and

  use {'neovim/nvim-lsp', ft = 'tex'}
  use {'haorenW1025/completion-nvim', after = 'nvim-lsp', setup = "require 'lsp'"}

(and _not_ requiring lsp manually). (This is without a buffer, so it's not actually loading.) Here's the generated loader:

" Automatically generated packer.nvim plugin loader code

lua << END
local plugins = {
  ["completion-nvim"] = {
    load_after = {
      ["nvim-lsp"] = true
    },
    loaded = false,
    only_sequence = false,
    only_setup = false,
    path = "/Users/clason/.local/share/nvim/site/pack/packer/opt/completion-nvim"
  },
  ["nvim-lsp"] = {
    after = { "completion-nvim" },
    loaded = false,
    only_sequence = false,
    only_setup = false,
    path = "/Users/clason/.local/share/nvim/site/pack/packer/opt/nvim-lsp"
  }
}

local function handle_bufread(names)
  for _, name in ipairs(names) do
    local path = plugins[name].path
    for _, dir in ipairs({ 'ftdetect', 'ftplugin', 'after/ftdetect', 'after/ftplugin' }) do
      if #vim.fn.finddir(dir, path) > 0 then
        vim.api.nvim_command('doautocmd BufRead')
        return
      end
    end
  end
end

_packer_load = nil

local function handle_after(name, before)
  local plugin = plugins[name]
  plugin.load_after[before] = nil
  if next(plugin.load_after) == nil then
    _packer_load({name}, {})
  end
end

_packer_load = function(names, cause)
  local some_unloaded = false
  for _, name in ipairs(names) do
    if not plugins[name].loaded then
      some_unloaded = true
      break
    end
  end

  if not some_unloaded then return end

  local fmt = string.format
  local del_cmds = {}
  local del_maps = {}
  for _, name in ipairs(names) do
    if plugins[name].commands then
      for _, cmd in ipairs(plugins[name].commands) do
        del_cmds[cmd] = true
      end
    end

    if plugins[name].keys then
      for _, key in ipairs(plugins[name].keys) do
        del_maps[key] = true
      end
    end
  end

  for cmd, _ in pairs(del_cmds) do
    vim.api.nvim_command('silent! delcommand ' .. cmd)
  end

  for key, _ in pairs(del_maps) do
    vim.api.nvim_command(fmt('silent! %sunmap %s', key[1], key[2]))
  end

  for _, name in ipairs(names) do
    if not plugins[name].loaded then
      vim.api.nvim_command('packadd ' .. name)
      if plugins[name].config then
        for _i, config_line in ipairs(plugins[name].config) do
          loadstring(config_line)()
        end
      end

      if plugins[name].after then
        for _, after_name in ipairs(plugins[name].after) do
          handle_after(after_name, name)
          vim.api.nvim_command('redraw')
        end
      end

      plugins[name].loaded = true
    end
  end

  handle_bufread(names)

  if cause.cmd then
    local lines = cause.l1 == cause.l2 and '' or (cause.l1 .. ',' .. cause.l2)
    vim.api.nvim_command(fmt('%s%s%s %s', lines, cause.cmd, cause.bang, cause.args))
  elseif cause.keys then
    local keys = cause.keys
    local extra = ''
    while true do
      local c = vim.fn.getchar(0)
      if c == 0 then break end
      extra = extra .. vim.fn.nr2char(c)
    end

    if cause.prefix then
      local prefix = vim.v.count and vim.v.count or ''
      prefix = prefix .. '"' .. vim.v.register .. cause.prefix
      if vim.fn.mode('full') == 'no' then
        if vim.v.operator == 'c' then
          prefix = '' .. prefix
        end

        prefix = prefix .. vim.v.operator
      end

      vim.fn.feedkeys(prefix, 'n')
    end

    -- NOTE: I'm not sure if the below substitution is correct; it might correspond to the literal
    -- characters \<Plug> rather than the special <Plug> key.
    vim.fn.feedkeys(string.gsub(cause.keys, '^<Plug>', '\\<Plug>') .. extra)
  elseif cause.event then
    vim.api.nvim_command(fmt('doautocmd <nomodeline> %s', cause.event))
  elseif cause.ft then
    vim.api.nvim_command(fmt('doautocmd <nomodeline> %s FileType %s', 'filetypeplugin', cause.ft))
    vim.api.nvim_command(fmt('doautocmd <nomodeline> %s FileType %s', 'filetypeindent', cause.ft))
  end
end

-- Pre-load configuration
-- Setup for: completion-nvim
require 'lsp'
-- Post-load configuration
-- Conditional loads
END

function! s:load(names, cause) abort
  call luaeval('_packer_load(_A[1], _A[2])', [a:names, a:cause])
endfunction

" Load plugins in order defined by `after`

" Command lazy-loads

" Keymap lazy-loads

augroup packer_load_aucmds
  au!
  " Filetype lazy-loads
  au FileType tex ++once call s:load(['nvim-lsp'], { "ft": "tex" })
  " Event lazy-loads
augroup END

" Runtimepath customization

[wbthomason]

Ok. Thank you for all the help and quick replies here - I have some work cut out for me (I've made issues for most new items), and I'll report back here if/when I figure out a good solution for (1) the weird issue with start packages and paths/ftplugins and (2) the relative slowness of loading start packages.

[clason]

Hey, it's the least I can do! Everything is working thanks to your help, so I'll keep test-driving it.

[wbthomason]

Thanks, and please do file more issues if (realistically, when...) you encounter more bugs/pain points.

[clason]

Will do! One thing I just noticed that the above workarounds don't seem to help with is with overriding a colorscheme: I have a few lines in my plugin like

colorscheme iceberg
hi! Comment cterm=italic gui=italic
hi! link Delimiter Character

which don't seem to get applied when I load the colorscheme via a package? The packadd/packloadall trick doesn't seem to help here. (And I understand that this is all only very tenuously related to packer itself, so I'm not saying this is a bug that should be fixed on your end...)

(Moving those to plugin works, though.)

[clason]

Just a brief update (and that's the last one, promised ;)):

I bit the bullet and (finally) moved most stuff out of my init.vim into separate files in plugin. Now everything works (of course), and I got a better profile of the complete lsp loading. Turns out sourcing the two lua plugins from start is in fact not much more expensive than from opt plus packadd! (~0.010 vs 0.008), and the total time is on par with the version via the compiled package loader I reported above. So it was just a case of me not being able to count...

[wbthomason]

Will do! One thing I just noticed that the above workarounds don't seem to help with is with overriding a colorscheme: I have a few lines in my plugin like

colorscheme iceberg
hi! Comment cterm=italic gui=italic
hi! link Delimiter Character

which don't seem to get applied when I load the colorscheme via a package? The packadd/packloadall trick doesn't seem to help here. (And I understand that this is all only very tenuously related to packer itself, so I'm not saying this is a bug that should be fixed on your end...)

(Moving those to plugin works, though.)

It seems that there's something very strange with sequencing of package loading and init.vim sourcing... I have noticed similar issues with other package-based plugin managers (e.g. vim-packager), which is part of why I moved my config to the "almost everything in plugin/" setup.

[wbthomason]

Just a brief update (and that's the last one, promised ;)):

I bit the bullet and (finally) moved most stuff out of my init.vim into separate files in plugin. Now everything works (of course), and I got a better profile of the complete lsp loading. Turns out sourcing the two lua plugins from start is in fact not much more expensive than from opt plus packadd! (~0.010 vs 0.008), and the total time is on par with the version via the compiled package loader I reported above. So it was just a case of me not being able to count...

Ah, that's good! I'm glad it's working.

[clason]

Yes, that was my take-away, too (see https://github.com/wbthomason/packer.nvim/issues/4#issuecomment-657082415 above) -- it's purely a packages and not a packer issue; my confusion stemmed from a) not being familiar enough (or, actually, at all...) with packages and hence b) fundamentally misunderstanding what packer does...

So feel free to close this issue; all that's left is a "maybe add a short explanation for dummies to the readme with links to the documentation" -- especially pointing out that packer (and packages) is _not_ a drop-in replacement for vim-plug (and runtime path mangling).

[carlitux]

Just to let you know, into gitter I got a reply that https://github.com/wbthomason/packer.nvim/blob/edfab0d155c7ee903cfa6cf03513e07de0198a38/lua/packer/plugin_utils.lua#L91 has a bug, needs to finish all Lua code to get package loaded.

[wbthomason]

@carlitux: Thanks! Yup, I think @tjdevries is referring in his response on Gitter to me asking about weird behavior with packadd from Lua (or maybe more people have asked about it too). I haven't seen it cause any issues in practice (for instance, I don't believe it could have caused the problems @clason reported here), but if you're experiencing bugs related to that weird Neovim behavior, please let me know (preferably in new issues for cleaner tracking).

[carlitux]

I think it is same with this init.vim

packadd packer.nvim
lua require('init')
lua require('config')

I am getting the following error for vim and Lua code also

Vim(let):E117: Unknown function: palenight#GetColors

But only

packadd packer.nvim
lua require('init')

and running manually

:lua require('config')

Works

[wbthomason]

So, that is surprising, but I don't think it's due to packer.

The first line

packadd packer.nvim

only loads the packer.nvim plugin. Since there are no plugin/ Vimscript files in packer, this has effectively no effect with regards to your next two lines (unless they require packer, etc.):

lua require('init')
lua require('config')

I can't be sure without reading your init.lua and config.lua, but I suspect that you'd observe :lua require('config') working if run manually after your first example, too.

I'd suggest checking (1) that you've installed your plugins by running packer.install(), and (2) if you have any lazy-loaded plugins, you've run packer.compile(<PATH>) per https://github.com/wbthomason/packer.nvim#compiling-lazy-loaders.

If you're still seeing errors, please open a new issue with your config (including init.lua and config.lua), and we'll see if we can figure out what's going on. I suspect (as discovered in https://github.com/wbthomason/packer.nvim/issues/4#issuecomment-657069004 and the following comments) that this is an issue with the native packages feature rather than with packer's use of that feature.

Thanks!

[tjdevries]

Maybe fixed by this: https://github.com/neovim/neovim/pull/12632

[wbthomason]

This might have been fixed by a58f7ec while we're waiting on https://github.com/neovim/neovim/pull/12632 (thanks to @tjdevries for letting me know about _update_package_paths() as a temporary workaround)

[clason]

That doesn't seem to be the case for me unfortunately; I still get packer not found when trying to require my plugins.lua from init.vim (works fine if requiring manually after startup).

(The plugin is installed in start, not opt. Putting it in opt and calling packadd as in the README example works. Actually, packadd also works if the plugin is in start...)

[Shougo]

@clason In first, you should create the minimal init.vim with your plugins.
We need to reproduce the problem to fix it.

You can check the script loading order by :scriptnames.

I think compiled vimrc is not loaded when loaded your plugin.

[clason]

@Shougo This is continuing from the above description. I know that lua functions from package path are not visible from init.vim (because they are sourced _after_ that), but my understanding was that the commit @wbthomason linked above fixed this.

Here's the minimal example:
init.vim:

lua require 'plugins'

plugins.lua (same as the example from the README, but with the first line commented out. note that packer is not installed in /opt, so packadd should actually error -- but it works if I uncomment the line)

-- vim.cmd [[packadd! packer.nvim]]
vim._update_package_paths()

local plugins = {
  'wbthomason/packer.nvim',
}

local config = {
  display = {
    open_cmd = '25new [packer]',
  }
}

return require'packer'.startup {plugins, config = config}

[Shougo]

(The plugin is installed in start, not opt. Putting it in opt and calling packadd as in the README example works. Actually, packadd also works if the plugin is in start...)

Ah, I get it. start packages are loaded when VimEnter timing(it is same with plugin/ loading).
But please see :help VimEnter.

                            *VimEnter*
VimEnter            After doing all the startup stuff, including
                loading vimrc files, executing the "-c cmd"
                arguments, creating all windows and loading
                the buffers in them.
                Just before this event is triggered the
                |v:vim_did_enter| variable is set, so that you
                can do: >
                   if v:vim_did_enter
                     call s:init()
                   else
                     au VimEnter * call s:init()
                   endif

It is executed after vimrc. So it is Vim/neovim feature.
If you need to call the plugin in init.vim, you should not use start.

[clason]

If you need to call the plugin in init.vim, you should not use start.

But isn't that _very_ counterintuitive?

And it doesn't explain why packadd works for _this_ start/ plugin...

[wbthomason]

start packages are loaded when VimEnter timing(it is same with plugin/ loading).

Huh. I did not know that. That's very helpful to learn; thanks @Shougo! Though I agree with @clason that it is unintuitive that start/ plugins cannot be used in init.vim, etc.

[clason]

At least not without the packadd... I understand now that the commit only removes the requirement for the vim._update_package_paths(), not for the packadd. I wonder if it would make sense to (optionally) have packer packadd! all _start_ plugins (assuming that's a negligible cost for already loaded plugins).

[Shougo]

And it doesn't explain why packadd works for this start/ plugin...

Because, :packadd update runtimepath manually.

Though I agree with @clason that it is unintuitive that start/ plugins cannot be used in init.vim, etc.

It is normal plugin behavior...
Users cannot use function in plugin/*.vim in init.vim.

[Shougo]

If packer.nvim update runtimepath manually like vim-plug or dein.vim, the problem does not exists.
But it uses Vim/neovim package feature. It depends on the feature behavior.

[clason]

Yes, this is exactly what I'm talking about here: It's a discussion worth having whether packer.nvim should behave more like vim-plug (making plugins "just work" by managing the runtimepath) or minpac (which has the same approach -- and the same problems -- as packer currently).

I don't know what the right answer here is. Note that this is also a special situation for lua plugins, since there's no lua mechanism analogous to config/plugins that get automatically executed _after_ packages are loaded. That means you currently need to put a small vimscript shim into plugins that requires the lua file rather than just doing this from your init.vim, which is not exactly a hardship but... less than ideal.

The situation is also a bit special for packer since with the new startup mechanism that creates vimscript wrappers, you can't just map a command to lua require'plugins'.update(), for example, as before (which worked fine since the lua file was required when executing the mapping, so the package was already loaded). (I know you can still use the old approach, but I'm anticipating other people hitting the same snag when following the README.)

And if anybody knows, it would be helpful to know the thinking that went into making start packages load _after_ vimrc -- there must have been a reason?

[Shougo]

there must have been a reason?

It has. Because, plugins must be loaded after vimrc in Vim.
The load is runtime level feature.
If Vim load plugins automatically, no timing in vimrc loading.
The plugins must be loaded after initialize in vimrc.

If user load plugins manually, plugins can be loaded in vimrc. User know after plugin initialized.

[PatOConnor43]

That means you currently need to put a small vimscript shim into plugins that requires the lua file rather than just doing this from your init.vim, which is not exactly a hardship but... less than ideal.

I ran into this issue when trying to set up packer + nvim_lsp. I opted to steal this from @tjdevries 's xdg_config repo.

With that, all my requires in other lua files seem to work just fine. Here is a stripped down gist that describes my current set up.
https://gist.github.com/PatOConnor43/e6f57ccc742ae0734bf1fb8c9f66370e

[carlitux]

Already handled in this way https://github.com/wbthomason/packer.nvim/issues/30, could help to have new ideas

[wbthomason]

@clason and others: I believe #81 implies this is no longer an issue, can you confirm?

[clason]

@wbthomason for start packages, it should -- at least it works for me now. (But there seem to be still a few issues with that patch to iron out?)

[wbthomason]

Yes, I think there's still some dust to let settle on that patch. That said, the patch + its corrections should fix this issue, so I'll close it for now. Please feel free to reopen if you feel I should wait/that #81 does not fix this problem!

[clason]

@wbthomason I think this can be unpinned now -- start packages have been fixed for a while, and the thread is too long to serve as a reference anyway...