Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TRACKING] Lazy loading roadmap #2632

Open
2 of 7 tasks
GaetanLepage opened this issue Dec 11, 2024 · 12 comments
Open
2 of 7 tasks

[TRACKING] Lazy loading roadmap #2632

GaetanLepage opened this issue Dec 11, 2024 · 12 comments

Comments

@GaetanLepage
Copy link
Member

GaetanLepage commented Dec 11, 2024

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.

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
Copy link

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
Copy link
Member

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"1.

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
Copy link

Eveeifyeve commented Dec 11, 2024

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
Copy link
Member

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
Copy link

Eveeifyeve commented Dec 11, 2024

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

@HeitorAugustoLN
Copy link
Member

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
Copy link

Eveeifyeve commented Dec 11, 2024

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
Copy link
Member

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
Copy link

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
Copy link
Member

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
Copy link

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants