[TRACKING] Lazy loading roadmap

[GaetanLepage]

Lazy loading roadmap

As #2602 was merged and #421 closed, we will use this new issue to track the remaining steps for a broader lazy loading (LL) support.

• Initial implementation using the lz.n backend (mkNeovimPlugin: add lazyLoad with lz-n support #2602)
• Add top-level documentation (docs/user-guide: add lazy-loading.md #2630)
• Advertise the feature on the README
• Migrate all relevant packages to mkNeovimPlugin to have more plugins supporting LL. ([TRACKING] Use mkNeovimPlugin treewide #2638)
• Remove "experimental" warnings (once stability¹ is confirmed)
• Support the lazy.nvim backend (lib/neovim-plugin: lazyLoad support for lazy.nvim #2620)
• Enable lazy loading by default on supported plugins ?
  -> Not sure about this one. Again, Nixvim is not a distribution. It should not do much OOTB (i.e. behind your back).

Feel free to propose additional goals !

Thanks @trueNAHO for the idea

Footnotes

1. Note: "stability" refers to both the feature itself behaving as expected, and also our API being stable enough that we should not need to make breaking changes ↩

[Eveeifyeve]

I feel like it should be default because it would be a pain to enable lazyloading for every single plugin.
An example, before lazyloading you have 50-100+ plugins that you have enabled and want lazy loading on all of them, it would be a pain to go ahead and enable lazyloading for all of them.

I feel like there should be a seprate option to enable lazyloading for all plugins by default on but users can turn it off if it's annoying. So an example of this could be:

programs.nixvim.plugins = {
   lazyloading = true; # false if you want to only select specific plugins
   
   # with the main lazyloading
   noice-nvim.enable = true;
   
   # Manually specifying plugins that you want lazyloading on
   noice-nvim = {
    enable = true;
    lazyloading = false; # This should still work if lazyloading is enabled in plugins as well as specifically affecting that plugin.
  }
};

I get this might sound complicated, but it could solve the lazy loading by default on plugins problem.

[MattSturgeon]

I feel like it should be default because it would be a pain to enable lazyloading for every single plugin.

I'm going to assume you mean the per-plugin plugins.*.lazyload.enable option should default to true. Having lazyloading itself globally enabled by default is not something nixvim will do, because everything in a nixvim config should come from the end-user explicitly deciding to do something.

The issue with having plugins.*.lazyload.enable default to true, is deciding what triggers individual plugins to be loaded. That is why it currently defaults to "whether plugins.*.lazyload.settings contains a non-null attr"¹.

See the documentation for more detail.

If it is set to true without any sensible config in plugins.*.lazyload.settings, then the plugin will simply never load. For lazy loading to make sense, you need to decide which keybinds, filetypes, autocmd events, etc should trigger loading.

Footnotes

1. default = lib.any (x: x != null) (builtins.attrValues config.settings) ↩

[Eveeifyeve]

I feel like it should be default because it would be a pain to enable lazyloading for every single plugin.

I'm going to assume you mean the per-plugin plugins.*.lazyload.enable option should default to true.

No, Just please have a look at the example provided.

[MattSturgeon]

I'm going to assume you mean the per-plugin plugins.*.lazyload.enable option should default to true.

No, Just please have a look at the example provided below.

I'm sorry, the example doesn't make sense because nowhere is it specified when the plugin should be loaded.

See the rest of my comment above, but as a TL;DR: lazyloading requires you to decide what "event(s)" should cause the plugin to load.

---

Also, as a side-note: your example doesn't match how we currently have the options structured:

• You're using plugins.*.lazyload as a boolean, but it is actually an attrset containing an enable and settings options.
• You have a "global" plugins.lazyload option, however we expect this to be configured as plugins.lz-n.enable.

[Eveeifyeve]

I will look into making a POC pr and it will hopefully make sense.

[HeitorAugustoLN]

I don't making lazy-loading enabled by default is good. Not all plugins should be lazy-loaded, in fact, many plugins can break if you lazy-load them. Plus, not everyone even likes lazy-loading, for them, lazy-loading by default would just feel like an unnecessary hassle.

Another issue is figuring out when plugins should load. If the triggers (like keybindings or filetypes) aren’t set up right, some plugins might never load at all. That’s a confusing problem to deal with, especially for new users.

I think the current way of enabling lazy-loading, only if the user passes specific configuration, is the right way. It ensures lazy-loading is only applied when the user explicitly sets it up

[Eveeifyeve]

I don't making lazy-loading enabled by default is good. Not all plugins should be lazy-loaded, in fact, many plugins can break if you lazy-load them. Plus, not everyone even likes lazy-loading, for them, lazy-loading by default would just feel like an unnecessary hassle.

Another issue is figuring out when plugins should load. If the triggers (like keybindings or filetypes) aren’t set up right, some plugins might never load at all. That’s a confusing problem to deal with, especially for new users.

I agree with this, I think it shouldn't be default after just now thinking, but there should be a global way and when you use the lazyloading option in the plugin it overrides the global like I said above.

I think the current way of enabling lazy-loading, only if the user passes specific configuration, is the right way. It ensures lazy-loading is only applied when the user explicitly sets it up

I still think there could be a couple improvements like adding a global option to enable it for all plugins and make it to so if you modify the plugin option it overrides what the global option does. I will make a pr of it soon!

[HeitorAugustoLN]

I agree with this, I think it shouldn't be default after just now thinking, but there should be a global way and when you use the lazyloading option in the plugin it overrides the global like I said above.

I don’t think having a global lazy-loading option is a good idea either. The main problem is that you’d need to set up the lazy-loading triggers in a way that works for most plugins, which is nearly impossible. Plugins usually need specific configurations to determine when they should load, like on a command, a keymap, an event, or something else.

And if you try to apply the same global lazy-loading configuration to all plugins, they’d all end up with the same trigger unless overridden. And at that point, you’re back to square one, either not actually lazy-loading most plugins or needing to override so many of them that the global option becomes pointless.

Lazy-loading really needs to be done plugin by plugin to make sense. It’s better to stick with the current approach where the user explicitly sets it up when and how it’s needed.

[Eveeifyeve]

I agree with this, I think it shouldn't be default after just now thinking, but there should be a global way and when you use the lazyloading option in the plugin it overrides the global like I said above.

I don’t think having a global lazy-loading option is a good idea either. The main problem is that you’d need to set up the lazy-loading triggers in a way that works for most plugins, which is nearly impossible. Plugins usually need specific configurations to determine when they should load, like on a command, a keymap, an event, or something else.

And if you try to apply the same global lazy-loading configuration to all plugins, they’d all end up with the same trigger unless overridden. And at that point, you’re back to square one, either not actually lazy-loading most plugins or needing to override so many of them that the global option becomes pointless.

Lazy-loading really needs to be done plugin by plugin to make sense. It’s better to stick with the current approach where the user explicitly sets it up when and how it’s needed.

I get that but that's why I mentioned there is a possibility of overriding it but just to enable lazy loading. Not settings as settings for how it will be loaded I just want a globalEnable option so you don't have to do for every single plugin plugins.*.lazyloading.enable = true;

[HeitorAugustoLN]

I get that but that's why I mentioned there is a possibility of overriding it but just to enable lazy loading. Not settings as settings for how it will be loaded I just want a globalEnable option so you don't have to do for every single plugin plugins.*.lazyloading.enable = true;

You don’t need to set plugins.*.lazyLoad.enable explicitly for every plugin. The way it works now, lazy-loading is automatically enabled as long as you pass the lazy-loading settings. For example, you can just set something like:

plugins.which-key.lazyLoad.settings.event = "VimEnter";

[Eveeifyeve]

I get that but that's why I mentioned there is a possibility of overriding it but just to enable lazy loading. Not settings as settings for how it will be loaded I just want a globalEnable option so you don't have to do for every single plugin plugins.*.lazyloading.enable = true;

You don’t need to set plugins.*.lazyLoad.enable explicitly for every plugin. The way it works now, lazy-loading is automatically enabled as long as you pass the lazy-loading settings. For example, you can just set something like:

plugins.which-key.lazyLoad.settings.event = "VimEnter";

But still I don't want to have to do that for every plugin that I want lazily loaded.

[MattSturgeon]

The way it works now, lazy-loading is automatically enabled as long as you pass the lazy-loading settings. For example, you can just set something like:

 plugins.which-key.lazyLoad.settings.event = "VimEnter";

But still I don't want to have to do that for every plugin that I want lazily loaded.

I don't see a sensible alternative.

If you want a plugin lazy loaded, you should have some idea of why you want it lazy loaded; i.e. when you need it loaded and when you don't.

Therefore you need to decide for yourself what events will cause that plugin to load.

If you don't do that, we can't really guess for you. Because while you might want to load on VimEnter, someone else might want to load on something entirely different. Or they may want the plugin eagerly loaded.

---

In theory, nixvim could maintain bespoke sane defaults for every plugin. However this is impractical because we have way too many plugins and we don't want to increase our already high per-plugin maintenance cost.

Even if nixvim did maintain per-plugin defaults, it still seems likely that many users would disagree with our choices. It'd actually be more work for them to "undo" our choices instead of starting from a blank slate.

[Mikilio]

I think it might be cool to use a sensible default equivalent to what is advertised on the plugins GitHub page, though that seems like a lot of manual maintenance, which at least I would not want to do.