Converted nixCats to nix-wrapper-modules

[dwinkler1]

I thought I'd share my converted config for Neovim now using nix-wrapper-modules. It is much cleaner, and packages only get installed if the corresponding cat is activated. The project-specific overrides are also much cleaner.

Here is the base config:

https://github.com/dwinkler1/nvimConfig

and the project template for overrides:

https://github.com/dwinkler1/np/blob/main/templates/ed/flake.nix

I know the base-config has some redundancies I'm working to reduce but it works.

[BirdeeHub]

You seem like you had a good time with this! You made a lot of your own options for your various languages!

Being in the module system lets you do whatever you want on top it is fun! 😸 I think it is a much better system this way.

This way you can make your own options, and override them later and you don't even need a special merge helper function to do the recursive merge like you did there to deal with the nested sets of things. It is a much more ergonomic experience.

I also really like that you broke it up into separate modules. This wrapper scheme has a MUCH better ability to do that.

I also really like how well you used the new hosts feature, allowing you to include your languages and tooling alongside your neovim and then exposing them as top level options as well. Very nice. It seems like you understood the new wrapper! 😸

I am hoping at some point people start making nvim language modules that I can import and enable to add a language config to my neovim XD That's why I added so much ability to pass lua from nix from within the specs themselves.

Maybe someone can figure out how to get java or something working correctly and do it in a way that doesnt use the config directory using the new ways to provide lua from nix! It should be similarly capable to nvf in that manner, and be able to support some interesting distros and/or collections of neovim modules in the future.

One could still use a directory, they could have a top level spec which uses its config field to add a dir the rtp, and then a list of plugins or whatever in that spec to install, and then pass in some info via that spec's info field to it and make it into nix options.

That would give a self-contained module that does some sort of feature, and then they could expose that with options like language.name.enable = true

---

I am also happy you liked nixCats enough to bring the cats idea here!

I did as well, but differently!

Personally I have had good success driving things the other way around. I.e. rather than enabling my specs based on an external category, I enable other things based on my top-level specs.

On the other hand, the way you are doing it allows you to nicely document what each cat does in an option description, which is nice. I hope to eventually allow people to use the docgen themselves when I fix it up more, and that could look very nice when that is possible.

I just enable or disable the specs, and for anything that doesn't go in the spec, I either include a toggle checking if that spec is enabled, or I use specMods to put it into the specs, and use specCollect to grab them from the specs and put them where they need to go, which won't get any disabled items.

You can see here for example, is my nix language spec. I can check if that spec is enabled or not for the info I pass with it. I can also override it on install with mynvim.wrap { specs.nix.enable = false; } or whatever.

In order to inform my lua of which specs are enabled, I have this mapping, which I put in the tips and tricks section of the neovim docs.

  options.settings.cats = lib.mkOption {
    readOnly = true;
    type = lib.types.attrsOf lib.types.raw;
    default = builtins.mapAttrs (_: v: v.enable) config.specs;
  };

This informs my lua of which specs are enabled via settings.cats.<name> and is readOnly, making it reliable.

---

However, I also found that for nix-installed plugins, I do not actually need to check if the cat is enabled?

I can simply check if the plugin is installed via an lze handler, which I put in the template and called auto_enable. lze requires the name to match the plugin name from nix anyway, so we can always see in the info plugin if it was provided. So in all my lze specs in lua I have auto_enable = true UNLESS the thing is not a plugin. In that case, I check the cat (the config.specs spec). I have found that handler to greatly reduce the amount of overhead I had about figuring out or changing which category something was in.

But for lsps and other things which are not plugins and could not be checked that way, I added the for_cat handler back too like from nixCats but checking my value in config.settings.cats instead and use that for those.

To be clear, I don't understand mini's later feature enough to know if you are already doing something like that, but I figured I would mention it.

---

Im still trying to decide if I want to give myself the ability to add items to info from my specs as well. You can already pass lua within the plugin specs but it is only provided to the config for that spec. I kinda like using the info plugin for some things, so I am considering adding a mapping for that to my config as well using specMods. It would work in a very similar manner it would just set into config.info instead of config.extraPackages

  config.specMods = {
    options.mainInfo = lib.mkOption {
      type = wlib.types.attrsRecursive;
      default = { };
      description = "an optional mainInfo spec field to add to the main info plugin instead of the spec specific one";
    };
  };
  config.info = lib.mkMerge (config.specCollect (acc: v: acc ++ lib.optional (v.mainInfo or { } != { }) v.mainInfo) [ ]);