feat: lazy-compatible integration with other plugins

[siimon]

Hi and thanks for a wonderful and useful plugin! I just noticed that fidget has now has support for the xcodebuild plugin (which is awesome too, thanks @wojciech-kulik!)

Discovered one issue with this, and it removes the possibility to have the xcodebuild lazy loaded (I use vim for other things than just iOS development, and it feels unnecessary to load xcodebuild at those times). I guess it's because fidget requires xcodebuild during setup?

I'm using lazy.nvim for lazy plugin management!

[j-hui]

Yeah unfortunately the way integrations are designed, Fidget require()s the xcodebuild plugin to register callbacks.

It might be possible to invert this dependency so that Fidget only sets up callbacks when xcodebuild is needed, but that sounds annoyingly complicated, AKA difficult to maintain, explain, and expand.

@wojciech-kulik and I had already discussed some kind of better integration paradigm starting here---with a filetype-based scheme, we might be able to avoid callbacks altogether. (Since Fidget renders according to a polling loop anyway, it shouldn't need to listen for "window resized" events, it'll just check the filetypes of open windows each time it needs to re-render.)

So I'm tempted to punt this issue until I have the bandwidth to implement filetype-based integrations. But I'm open to hearing your thoughts (and @wojciech-kulik 's!) on this.

[wojciech-kulik]

Hmm, what if we could expose some dynamic setup for integrations? For example, the config could stay as it is, but the user would have the possibility to set:

integration = {
   ["xcodebuild-nvim"] = {
       enable = false
   },
}

and then do something like:

require("fidget").integrations.setup("xcodebuild-nvim", { enable = true })

This way the user could decide when to enable it.

[wojciech-kulik]

Or alternatively, we could introduce:

integration = {
   ["xcodebuild-nvim"] = {
       enable = true,
       lazy = true,
   },
}

And the integration would decide how to handle lazy.

I guess, the first option is more versatile, and the second is easier for users but less flexible.

---

Btw. in general, I'm wondering how important is lazy loading in Neovim, when I check profiling information it shows like most plugins start in around 10ms. But I guess it's more a matter of a clean environment without extra auto commands registered, bindings, etc.

[siimon]

Btw. in general, I'm wondering how important is lazy loading in Neovim, when I check profiling information it shows like most plugins start in around 10ms. But I guess it's more a matter of a clean environment without extra auto commands registered, bindings, etc.

That's a valid point, it's probably the minimalist in me talking and has no real practical reason as of now. So I'm totally fine if this gets punted to the future.

I don't have much experience in either lua and writing neovim plugins so my advice around best solution for this is probably not worth much - but your first suggestion sounds more configurable and could potentially be used in other use cases too. Filetype integrations sounds really smart though!