Minimal Neovim Config Example

[d-hain]

I have been trying for days to minify this template and get a minimal example to work.
I don't want any lazy loading and basically just move my existing config over to nix-wrapper-modules using Nix instead of lazy.nvim.

What is THE most minimal example for using nix-wrapper-modules?
Because ngl this template seems hella bloated.

[BirdeeHub]

Well, after you scroll down past the vim.opt options, you will see the lze specs that lazily load and configure the plugins.

The functions in those specs contain the config code for the plugin.

So, you take that code in the function and put it anywhere outside of the call to lze.load

Then in the nix code, you remove everywhere it says lazy = true

This is because plugins installed with lazy = true do not load until you call packadd on them. If you don't want lazy, you will want them to just load.

Remove anything else relating to lze, and that's it!

In the process of that, feel free to remove any plugins you don't like, and their associated config.

---

The confusing part of doing that is likely to be converting how I did the lsps to not use lze.

The lsp field in the specs for nixd and lua_ls just gets fed to vim.lsp.config("name", thesettings); vim.lsp.enable("name")

Before that, the nvim-lspconfig spec will run vim.lsp.config("*", { on_attach = ... }) to set up the global lsp config

It just has been put into a spec so that it only calls vim.lsp.enable when it is actually needed for the current filetype, rather than scanning the rtp for the config for every lsp you may have configured directly at startup. (vim.lsp.enable eagerly searches the rtp for configuration when called)

---

As an aside, I am not sure if "hella bloated" is a great description. Maybe slightly bloated, depending on your general tastes.

Snacks isn't bloat (in this config), it is being used for the lsp workspace stuff, and a few other things, such as fuzzy finding. You likely would want a replacement for it if you removed it. There are great replacements of course, but I had to choose a plugin for fuzzy finding and snacks has a few more things that are useful, so I chose that.

which-key is probably bloat, but a premade config of any kind should should give its users a pop up to tell them what keys exist.

lualine might be bloat, as might a colorscheme, fidget.nvim, lazydev, and vim-startuptime. I personally don't necessarily agree, and lua plugins without external dependencies are very small, and the ones chosen do not have performance issues, but it is your config, remove what you wish.

it also has nvim-lint, conform, nvim-treesitter, nvim-treesitter-textobjects, and nvim-lspconfig. These are used to set up core things such as completion, linting, formatting, and things like incremental selection. The vast majority of the neovim userbase has these installed. They definitely are not bloat, unless you consider lsps and formatters bloat.

Blink might be bloat if you like the builtin completion. I don't really, and most use a plugin to make use of sources which do not conform to the lsp api. It also has 2? extensions for it, mostly as a demo, but also because the colorful menu is nice.

And then it has lze for lazy loading.

---

Defining what bloat is is hard. And I wanted to show that lazy loading on nix is not more strenuous than using lazy.nvim

The biggest contributor to the initial installation time is that I installed all the treesitter grammars rather than just some of them. I did give instructions in the template how you might limit it to only install the ones you want.

In addition, the 2 lsps it installs (nix and lua) make up the majority of the size of the closure created, but those generally install quickly thanks to the nixpkgs binary cache.

nvim and the other plugins combined are very small and make up very little of the final disk size, and the plugins chosen have little effect on runtime performance.

If you wanted to see a bloated config, you should check out mine 🤣 (but it doesn't feel that way, it loads in 60-80ms, bloat matters more for security than speed if you use lazy loading, and I read the plugins I install)

[d-hain]

First off, sorry for being a little rude. There is a minimal example in the templates' README.md. The module.nix specified is just showing off very much to comprehend at once.

I have tried what you suggested and came to this config: d-hain/NixOS@40b8cea
(you can ignore everything past the 1st line in the init.lua)
But the config is just not getting loaded (print is not printing anything on opening neovim) even though everything is building fine.
Would you know what is going wrong here?

[BirdeeHub]

It looks like you are not exporting it from your flake, and you are only installing it via home manager?

That is fine, totally valid but if you don't export it as well, it does make it a bit harder to test it in isolation.

When I took the files out, and executed them on their own it seems to work

What I believe to be happening, is that you already have neovim installed and that one is winning somehow, rather than the one installed by that module.

Heres the other place where you are installing it.

https://github.com/d-hain/NixOS/blob/40b8ceac64732b31979be9bb29c8b38b81efc051/modules/user.nix#L84

I think if you remove that, and/or use lib.mkBefore or lib.highPrio on the one provided by the wrapper, that should solve the issue?

---

On that note, when I ran it on its own, it appears you have a syntax error in the config.

Nothing major, just missing an end parenthesis

https://github.com/d-hain/NixOS/blob/40b8ceac64732b31979be9bb29c8b38b81efc051/modules/init.lua#L157

---

That being said, I also found a bug. It is not related to your issue necessarily, but I have fixed it and you will want to update.

[d-hain]

... and you are only installing it via home manager?

My own option that wraps users.users.<username>.packages.
But basically yes.

... but if you don't export it as well, it does make it a bit harder to test it in isolation.

That's true. I have never thought about that, good idea 👍

[BirdeeHub]

Yes. Being able to be separately exported is a core advantage of using wrapper scripts to configure as opposed to normal home manager and nixos modules.

To test a change to your home manager config, you must rebuild your whole home manager config.

To test a change to a wrapper derivation, you need only build THAT derivation.

This is useful for a few reasons.

1. You can test if the issue is in that wrapper, or elsewhere (as I did to debug this question)

2. pulling home manager on someone else's machine moves their existing dotfiles, something that just installing a wrapped package does not do, as it is just a derivation like any other you may install. With a wrapper derivation, you can use anything you can build a package with. nix build, nix profile install, nix shell, etc.

3. building the whole config is often kinda slow. And if you break your config, now your config is broken. Being able to build it separately means, you can have the one currently installed on your machine, then test a change by editing the config and building just that package with nix build. When you are happy with your changes, THEN you do the home manager rebuild. This is both faster feedback, AND you still have your old config to fall back to if you broke it on the first try (even more useful for nvim, as you need a working editor to edit the config)

[d-hain]

Okay thanks for the quick fix.
Works perfectly now. Also I only saw your original reply without the edits (thanks GitHub)

In regards to my bloated comment:
I meant more like that the template had everything in it, as to just having a most minimal example.
This is my first time using nix-wrapper-modules (or any nix wrapper in general) and I used this template more as a tutorial and an example for that.
The template it totally fine, it just felt much for a first example to look at.
(Also I definitely relied way too much on AI here 😅)

Thank you very much for the quick and detailed replies ❤️. I'll now get to configuring some more.

[BirdeeHub]

I meant more like that the template had everything in it

The main priority was to demonstrate all the main points people ask about.

Those being, lsps, lazy loading, formatters, treesitter, completion. And then have the demo config feel semi-ok on top of that.

That way, I can link to concrete examples when people have questions, and otherwise just try to improve the docs to better orient new users and anticipate further questions.

I wanted it to be minimal and 1 file, but, if you have to demonstrate all those things, it becomes more difficult to make it minimal.

I based it on https://github.com/nvim-lua/kickstart.nvim + these 2 templates from nixCats https://github.com/BirdeeHub/nixCats-nvim/tree/main/templates/example https://github.com/BirdeeHub/nixCats-nvim/tree/main/templates/simple

I only wanted 1 neovim template in this project.

This is because this is meant to be a generalized project, for wrapping anything. I cannot be chasing down random issues across multiple neovim template configs while also dealing with who knows how many other programs.

But I also wanted to make sure I could provide good onboarding for the users of nixCats, which was my neovim wrapper that I wrote and used up until I made this.

So, I settled by putting the skeleton version in the template's readme, and then having just the 1 template where I showed what I hope is just enough such that people can see how to do the important things they were used to from nixCats here.

[BirdeeHub]

Also I like to leave discussions where people ask questions and get answers open, because it is hard to find issues that have been closed, and other people may have this same question.

I close them if they end up spending most of their time discussing something that has been deprecated.