feat: smart lazy-loading + no forced setup

[mrcjkb]

Closes #114

I've tested this by adding the plugin's nix flake output to my nvim config.

Things done:

• Split configuration and initialization
• Refactored configuration to allow you to use both require('fff').setup(config) and vim.g.fff = config.
  The config is validated the first time it is requested internally via require('fff.conf').get().
• Fixed an attempt to index nil value error when opening the picker.
• Initialize the plugin lazily. To make it initialize eagerly, set lazy_sync = false in the config.
• If initializing eagerly, defer until after UIEnter (this is equivalent to initializing on lazy.nvim's VeryLazy event).
• Create commands in the plugin/ script. The commands require fff's Lua modules lazily, so this has less startup overhead than would be needed to create lazy-loading configurations with lazy.nvim.

[jla2000]

Suggested change

	build = "cargo build --release",
	build = "cargo build --release",
	-- Prevent lazy.nvim from lazy loading plugin
	lazy = false,

Would it make sense to add this to the suggested plugin spec?

[mrcjkb]

I don't use lazy.nvim, so I don't know for sure. But I believe adding keys = ... makes it lazy-load? Not sure if setting lazy = false overrides that?

I could also put the keymap example in a separate code block that uses vim.keymap.set.

[jla2000]

Hmm I'm also not sure keys would make it lazy load again, even when lazy = false is specified.

At least for default.config.lazy it seems to get overriden by keys according to this page: https://lazy.folke.io/spec/lazy_loading

[jla2000]

Maybe the safe way would really be to set lazy = false and then use vim.keymap.set in a config() function inside the plugin spec

[mrcjkb]

lazy-loading isn't bad. It's just redundant.
But I do think using vim.keymap.set is a better example, as it also works for users of other plugin managers.

[mrcjkb]

I've added an init with vim.keymap.set.
Note: I chose init over config, because if you use config, lazy.nvim won't automatically pass the opts to the setup function.

[dmtrKovalenko]

Sorry for the long response—I had a very busy week.

I tested it out, and it appears to be working, although the lazy sync never actually started before the picker is open. Perhaps I'm missing something?

Also, I (and I believe most lazy users) prefer setting up the plugin using keys = {} and opts = {} and controlling laziness solely via the lazy property. I understand why we need the lazy_sync property, but if we're lazy-loading the plugin using lazy.nvim, can't we just set lazy_sync to true by default so it starts syncing once it's initialized by lazy?

[mrcjkb]

No problem 😄
I'm not in a rush.

I tested it out, and it appears to be working, although the lazy sync never actually started before the picker is open. Perhaps I'm missing something?

Should be fixed in the latest commit. I tripped over the nil/false duality.

Also, I (and I believe most lazy users) prefer setting up the plugin using keys = {} and opts = {} and controlling laziness solely via the lazy property.

Okay, I've reverted the lazy.nvim example modification to use the keys field again.

I understand why we need the lazy_sync property, but if we're lazy-loading the plugin using lazy.nvim, can't we just set lazy_sync to true by default so it starts syncing once it's initialized by lazy?

I'm not sure how that would work?
If someone configures lazy.nvim to lazy-load the plugin using a keymap or a command, lazy.nvim will trigger the keymap or command, which will result in ensure_initialized being called.