-
-
Notifications
You must be signed in to change notification settings - Fork 292
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
Comments
I feel like it should be default because it would be a pain to enable lazyloading for every single plugin. 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. |
I'm going to assume you mean the per-plugin The issue with having See the documentation for more detail. If it is set to true without any sensible config in Footnotes
|
No, Just please have a look at the example provided. |
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:
|
I will look into making a POC pr and it will hopefully make sense. |
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 |
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 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! |
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 |
You don’t need to set 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 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. |
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.
mkNeovimPlugin
to have more plugins supporting LL. ([TRACKING] UsemkNeovimPlugin
treewide #2638)-> 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
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 ↩
The text was updated successfully, but these errors were encountered: