lazy-simple

[khaneliman]

No description provided.

[traxys]

I think we should try to do the plumbing to lz.n ourselves (though it's a larger change)
We could introduce a luaConfig.requireMethod that's an enum of init (the current way, added to init.lua), lz.n (added to lz.n), <another lazy provider> (added to the other lazy provider) and none, which would result in what you proposed, with the user able to choose as he wants.

Maybe a good first step would be supporting only init and none, doing a second step for the lazy loading provider

[MattSturgeon]

Maybe a good first step would be supporting only init and none, doing a second step for the lazy loading provider

I'm wondering about maybe allowing either bool submodule?

For now it could be just bool, where if true we add the config to init.lua and if false we do not.

In the future we can add either submodule or either (coercedTo str _ submodule) to allow users to define a lazy spec specifying which lazy loader to use and what events will trigger loading the plugin.

I also wonder whether which lazy loading implementation to use should be a global option or a per-plugin one? Surely it wouldn't make sense for multiple lazy loaders to be used simultaneously?

Perhaps it would be enough to just figure out which lazy loading plugin is enabled? And assert that multiple are not enabled at the same time?

[traxys]

The issue I could forsee is that not all lazy providers could present the same API, meaning that we would not easily provide a RFC-42 style submodule, though this may not be a large issue if all lazy loading providers use a common interface

[Eveeifyeve]

When enabling lz-n, it should automatic in each plugin enable lazyloading then you have a choice to disable lazyloading if need to (for issues,) but I feel like it would save like between 1-50 lines of code plus having a benefit of cleaner code in a nixvim config.

[MattSturgeon]

If enable has its own default, this top-level default can simply be {}

[MattSturgeon]

I'm wondering, if it is likely we will have a different "enable" in the future, should this be named something else?

Having it named something like dontCallSetup may be more explicit and would also allow us to more easily deprecate this option if we need to in the future?

[MattSturgeon]

Q: I like this initial implementation, but do you think it is too much of a stretch to go straight to implementing this ourselves in this PR?

That way we never have the interim stage of end-users having to enable a "dont setup" option and passing their plugin's settings to another plugin which lazy-loads them.

[khaneliman]

I have another branch i'm playing around with right now for setting up lz-n for a user following the work done in #1875

[khaneliman]

Yeah... I thought about that when I started going through and implementing my own lazy loading. It felt tedious enough, let alone if I had to redo it again.