Hello everyone
For update(manifest): `serverPath` default to `nixd` by Malix-Labs · Pull Request #505 · nix-community/vscode-nix-ide · GitHub (amongst other)
I am polling the community for Nix LSPs preferences
- nixd
- nil
- rnix-lsp
Hello everyone
For update(manifest): `serverPath` default to `nixd` by Malix-Labs · Pull Request #505 · nix-community/vscode-nix-ide · GitHub (amongst other)
I am polling the community for Nix LSPs preferences
I’d really like it to be nixd, but it currently lacks code actions, which ends up being most of what I use the LSP for in nix land.
The completion features are nice in theory, but take configuration effort and aren’t great performance wise. I find nil is a more featureful zero-setup option, and would therefore be my preference for a default setting, with nixd hopefully replacing it in the long term.
But that’s just my 2c.
FWIW, I’ve had that issue open for months intending to sit down and just implement my most used actions, but I hate doing C(++) development so something else always takes priority.
I never stayed on nixd because I don’t know how to configure it.
Matt’s config is very well rounded
I actually use both. I find Nixd completions to be a lot better, but prefer Nil for everything else. To use both without the features colliding, I disable completions for nil, and disable everything except completions for nixd.
“Prefer” is a strong word. rnix-lsp is dead so of course that’s not an option. nixd breaks with flakes (yes, I’m aware of GitHub - inclyc/flake-compat yet the LSP crashes multiple times per second last time I tried using it with nixd for completions, then at some point the completions are gone entirely) and nil doesn’t complete my own custom options.
I also remember nixd being a bit annoying in terms of needing to hardcode paths to bits of nix code - I genuinely don’t understand how people use nixd productively.
Still, I don’t really care about the default for the extension, as at the end of the day, I’m configuring the serverPath manually. I use nil as it’s the only thing I managed to get working.
I use nil as it’s all I’ve been able to get working. I tried using nixd, but could never get it quite “context-aware” enough in Neovim to switch, so I eventually gave up on it. I will re-visit it in the future since I know that it is still under active development. nil isn’t perfect either since I’ve found that it doesn’t do the best job of handling when the syntax tree has errors in it. At times it just crashes and has to be restarted. I use it with Neovim.
I expect it’s easier if you only develop on one or two projects and don’t care that other nix files lack LSP entirely.
But yeah, this is mainly why I would stay away from making it a default for something where 90% of users just want to click install and expect stuff to work™ - while I would always change that default, defaulting to nixd is just adding to the newcomer nightmare; now they suddenly need to learn to configure something that needs no setup for pretty much every other ecosystem.
Sure, but then declaratively configuring it doesn’t feel like it makes sense, because you’re hardcoding a path to a disconnected project on your filesystem, and you can’t even relocate a project without rebuilding your config (feels like a massive layering violation). And yeah I tend to jump between dozens of projects, ideally they’d Just Work.
Since most of my interaction with the Nix language is in through my NixOS config, I found nixd to be the most useful for my use case. I have a Helix + Nixd configured to give me option completion for NixOS, third-party flakes like Home Manager, Hjem, Catppuccin etc., and my own custom options. For snippets and code actions I use hx-lsp. My biggest gripe with nixd is the increase in disk writes when opening a .nix file (>400 MS/s). Sometimes my PC locks up for 5-10 secs. An option in Helix to disable LSP auto-start would probably be useful.
When I’m in a fresh Nix environment, a Nix shell with Helix and nil is usually enough for me.