I can see in vim how we can:

But I want to:

  • Call function only when the plugin is required
  • I want to run one-time setup when my optional plugin (to be loaded with packadd) is loaded. But I cannot find the Autocmd to run after a packadd. Maybe there is an autocmd after a require was my next thought. Commented Jul 26, 2023 at 2:20
  • require is Lua semantics. You'd have to change its behavior somehow.
    – D. Ben Knoble
    Commented Jul 26, 2023 at 13:50

2 Answers 2


This is pretty much standard sequence of steps.

  1. Install plugin under opt subtree
  2. Execute packadd when required
  3. Initialization works the same way as with regular plugins but right after packadd executed for the first time.
  • Initialization works the same way as with regular plugins - with regular plugins I will have some code in my ./plugin folder (not my ./pack/start/* folder(s)... this ./plugin code will run unequivocally on startup. However, if I only wanted to run that code when I packadd matchit or something like that... then how do I do THAT. What is the mechanism of step 3? A plugin will have it's own ``./pack/opt/bundle/some_plugin/plugin/init.lua` folder to initialize itself. But I want to do additional work in my ./plugin/additional_config_for_some_plugin.lua file Commented Jul 26, 2023 at 20:44
  • @AriSweedler Vim plugins normally do not require user calling any setup function for that reason. But with Neovim/Lua they do believe that "opt" is of limited use as they can "require() for everything". So if you encounter a situation where some plugin poorly fits under /start but still needs too many setup function call(s) then you have to admit it's a dumb piece of code and you'd better to drop it.
    – Matt
    Commented Jul 27, 2023 at 8:22
  • @AriSweedler Otherwise, you won't have anything better than wrapping both "packadd" and "plugin setup call" into a single function and/or command and use it like that. A dubious design, imo, but sometimes it gets use. See "loading on demand" section of k-takata/minpac, for example.
    – Matt
    Commented Jul 27, 2023 at 8:25
  • Oh interesting. So I should be using functions that require the plugin code instead of opt to delay loading a plugin. My use case is that I'm using copilot.nvim and I don't wanna load it until I manually load it. I'm sure I can trivially figure out what specific config delays loading of the plugin and also write a small command that lets me load it later. It's just stupid that I can't use the perfectly fine packadd command to do this. Maybe I'll just make a command that runs setup and THEN calls packadd. Exactly as u said Commented Jul 27, 2023 at 21:45
  • @AriSweedler It is much simpler always to start it but with disabled functionality.
    – Matt
    Commented Jul 28, 2023 at 1:36

I'm starting to set up my environment now and 10 months after your question I'm having the same problem.

The packadd documentation says that the directory should follow the structure pack/*/opt/{name}/plugin/**/*.{vim,lua}

Well, the runtime sorts the directories by putting last the ones that start with after (in a nutshell, that's it), so what I did was add my scripts in after/pack/*/opt/{name}/plugin/**/*.{vim,lua}. With this, when I run the packadd {name} command, my settings are executed after the original settings of the script I loaded.

Well, it may not be so flexible and maybe difficult to manage, but it was as close as I could get.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.