plugins/fzf-lua: init + test

[budimanjojo]

No description provided.

[budimanjojo]

I don't know why the test fails, I tested locally without my addition and it fails too.

[budimanjojo]

Okay I managed to fix the failed check issue 🥳

[budimanjojo]

@GaetanLepage Done!

[budimanjojo]

@GaetanLepage is there any other issue that I need to fix?

[GaetanLepage]

Hey, sorry for taking so long.
Everything looks nice for now. However, I would encourage you to wrap the plugin options like we do for the other plugins.

The simpler way would be to limit the scope to the "global options" that would end up in the setupOptions attrs.

If you want to go a bit further, you could create a keymaps option that allows the user to create mappings easily (like we do for telescope or harpoon for instance).
You could even add options for the keymaps to be configurable.

I suggest to limit the scope of this PR to the default options though.

[budimanjojo]

Thanks! I'll try to add keymaps and keymapsSilent option for now. I don't think I understand the "wrap the plugin options like we do for the other plugins" part. Do u mean I need to add more options instead of making users to use extraOptions for everything else?

[GaetanLepage]

Do u mean I need to add more options instead of making users to use extraOptions for everything else?

Yes exactly. It is a bit of a pain to do, but it is one of the added value of nixvim ;)

[budimanjojo]

@GaetanLepage I added keymaps options. I don't know if my nix knowledge is good enough to create all those setup options without making the code looks messy. Maybe it's just me but I think people should just be good with changing the provided profile (or theme) and override the provided profile options per keymap like I provided in the example.

Maybe you can accept this PR and maybe if somebody else want to improve this plugin then he/she/they can make another PR?

[budimanjojo]

I also agree that having the setup options added in can be some kind of type checking at build time in case the user provided a wrong options it will fail to build resulting in the user must fix that up to continue building instead of having a broken neovim config. But I'm just not good enough to make it robust. I think the better way to go is to have all the available options in a variable that can also be used for the actionOpts in the keymaps in my last commit.

But, there are a lot of options that are action name specific, i.e cwd is only available in files action and this makes my brain hurts just by thinking about it 😅

[GaetanLepage]

I think that what you have done until now is good.

I would still want to package the options.
If you allow me to do so, I can complete this work by force-pushing to your branch.
Does that sound good to you ?

[budimanjojo]

@GaetanLepage I have commited the requested changes. Yes feel free to push to the branch! Thank you!

[GaetanLepage]

This is finally ready ! Sorry @budimanjojo for taking that long...

[budimanjojo]

Thank you!