[TRACKING] Use `mkNeovimPlugin` treewide

[khaneliman]

Just creating a tracker to keep track of what plugins need to be migrated to modern mkNeovimPlugin.

• ./plugins/by-name/alpha/default.nix (neovim) plugins/alpha: migrate to mkNeovimPlugin #3040
• ./plugins/by-name/coq-thirdparty/default.nix (neovim) plugins/coq-thirdparty: migrate to mkNeovimPlugin #3846
• ./plugins/by-name/efmls-configs/default.nix (neovim)
• ./plugins/by-name/treesitter-textobjects/default.nix (neovim) plugins/treesitter-textobjects: migrate to mkNeovimPlugin #3825
• ./plugins/pluginmanagers/lazy.nix (neovim) plugins/lazy: migrate to mkNeovimPlugin #3835

[Eveeifyeve]

When I was building the documentation for nixvim on darwin I ran into this:

error: builder for '/nix/store/dsq7xp5801qssx0a9yavnmqii6lkz5nd-nixvim-docs.drv' failed with exit code 1;
       last 3 log lines:
       > structuredAttrs is enabled
       > Running phase: buildPhase
       > cp: cannot create regular file 'plugins/efmls-configs/setup/html.md': Permission denied
       For full logs, run 'nix-store -l /nix/store/dsq7xp5801qssx0a9yavnmqii6lkz5nd-nixvim-docs.drv'.

This might be related to fixing nixvim documentation to build on darwin.

[jolars]

Maybe it would be worth it to separate this into separate issues so that they can be tracked and closed automatically as PRs targeting them are merged?

[GaetanLepage]

Maybe it would be worth it to separate this into separate issues so that they can be tracked and closed automatically as PRs targeting them are merged?

Not sure about this... It would lead to a lot of them.
We have the script (list-plugins) to have an overview of plugins that need to be migrated.

[Eveeifyeve]

Is it possible to write a script to rewite the options for mkNeovimPlugin?

[GaetanLepage]

Is it possible to write a script to rewite the options for mkNeovimPlugin?

Well, it would maybe be possible, but it would never be exhaustive. There are a lot of edge cases and it would be a very complex endeavor. "Old" non-mkNeovimPlugin implem are quite heterogeneous.

[Eveeifyeve]

I mean you could make it only compatible with certain option definitions then for everything else left should be done manually.

[GaetanLepage]

I mean you could make it only compatible with certain option definitions then for everything else left should be done manually.

Yes, you could surely implement some partial solution that could alleviate a part of the burden. Of course PR/ideas are welcome :)

[jolars]

I had a bit of success using copilot for this purpose. I think if you setup a prompt correctly with a couple of examples of before-and-after versions of some plugins, then it would probably do a very good job of at least making an initial conversion for some of the simpler plugins.

[khaneliman]

I had a bit of success using copilot for this purpose. I think if you setup a prompt correctly with a couple of
examples of before-and-after versions of some plugins, then it would probably do a very good job of at least making an initial conversion for some of the
simpler plugins.

I remember doing hat for a couple and it works very well if you find examples that handle all the option types relevant to the file you're converting.

[khaneliman]

Playing around with copilot chat prompts in my neovim config https://github.com/khaneliman/khanelivim/blob/main/modules/nixvim/plugins/copilot/migrateNixvimPlugin.nix to see if it can help ease some of the boring tediousness. If anyone wants to try it out, too.