Packer.nvim: Lazy load on require Lua module - possible?

Created on 3 Dec 2020  路  10Comments  路  Source: wbthomason/packer.nvim

Hey,
this plugin manager looks pretty cool! I like the native package support with all those fancy features on top. :+1:

I'm always very interested into lazy loading functionality. I simply have a too big setup and use nvim too often for many small things where I simply don't need everything. With the rise of Lua plugins, key mappings that require a Lua module and execute a function becomes more and more common. So I was wondering if the good old lazy load on command/function call could also work for such cases? I saw that there is the feature to lazy load on keys. But that creates a (horrible - at least for this case) dependency that I would love to prevent under all circumstances.

Since I basically have too less knowledge about the internal details, do you know/think it is possible to make such a feature possible? Thanks for your feedback!

enhancement help wanted

Most helpful comment

I suppose we could also add logic to scan plugins for the lua/** directories and determine the possible module names to lazy-load that way.

All 10 comments

If I understand what you're asking correctly - you want to be able to lazy-load Lua-based plugins via a command - then that should already be possible with packer through the cmd key. That works by defining a "fake" command that uses packadd to load the plugin (at which point the "real" command replaces the fake one packer generated), then calling the real command defined by the plugin.

So, if you have a Lua-based plugin that defines some command that requires a Lua module and runs a function, this will already work for you.

If I've not quite understood what you're asking about, could you give me an example of what you're looking for?

Thanks!

Thanks for your detailed answer!

Yeah, for a command that's works. That should be basically the same as for VimL, Python, Ruby... (?) plugins. But many Lua plugins are lazy or think it just makes no sense (because it is eventually more cumbersome to call a command in Lua configs than calling a function?). So lets say you have a mapping like noremap silent <leader>a <cmd>lua require('the-plugin.one-module').foo()<CR>. It would be cool to lazy-source the-plugin when any of its Lua sub-module gets required. I mean ofc it must not be a mapping. Could be also an auto-command or what ever.

Ah, that's interesting. There might be a way to do this by hooking into Lua's package search mechanism, but the trick will be knowing what modules a plugin contains.

If we're given a list of module names, we might be able to intercept attempts to load those modules, perform a packadd to load the relevant plugin, and then allow the load to continue? I'll need to figure out more of what's possible when messing with package, though.

Yeah, ok. This looks feasible with some package.preload or package.loaders cleverness.

If you feel like working on this yourself, I'd be happy to provide guidance and merge a PR. Otherwise, I'll add this to the list of features I want to implement.

I suppose we could also add logic to scan plugins for the lua/** directories and determine the possible module names to lazy-load that way.

Wow. This reads great!
Oh dear, I have way too less knowledge about this whole stuff. I eventually could start to read into the project. I can write some Lua, but regarding the whole internals/eco-system I'm a young novice. Also the plugins I need to start digging into is on-counting. :see_no_evil:
So if that is okay I would first put it on that feature list. If it does not get implemented after some time I will consider to invest the time again. :upside_down_face:

Sounds good, no worries. If anyone else wants to take this up, the same offer stands!

I want to add that https://github.com/Shougo/dein.vim/commit/c6ddf04183606413870a0f8a86f61f8d58f85982 provides a reasonable example of how we could implement this.

Amazing. :rocket:

(also, goes without saying, always happy to look at PRs!)

Was this page helpful?
0 / 5 - 0 ratings