Where do LSP "quirks" belong in the new lsp module API?

[jfly]

In the older plugins.lsp API, plugins/lsp/language-servers/default.nix has a huge collection of very useful options and sane defaults. For example, I recently learned about enabling volar automagically enables ts_ls and reconfigures it with the appropriate plugin. Really awesome, useful stuff.

As far as I can tell, we don't have a place for stuff like this yet in the newer lsp module API. To accomplish this, I had to put a version of that config in my personal nixvim config (jfly/snow@f4b37e5).

Is there a home for this and I just haven't found it yet? Or is this all still being figured out, and that's what #3745 is tracking?

[MattSturgeon]

Is there a home for this and I just haven't found it yet? Or is this all still being figured out, and that's what #3745 is tracking?

This is something that's still undetermined, but it's a separate issue to #3745.

That issue is about how we should represent the config passed to vim.lsp.config().

Firstly, there's a fundamental difference between lsp and plugins.lsp: the former just represents neovim's builtin lsp API, while the latter represents nvim-lspconfig; a repository of configs for servers.

With the new system, that is split into plugins.lspconfig. That plugin simply adds nvim-lspconfig to the rtp, and is meant to be used in tandem with lsp.

While lsp is first-and-foremost supposed to represent neovim's API as nix options, we do add some additional sugar, such as the lsp.servers.<name>.package option. This option is unrelated to the neovim API and simply adds lsp packages to the nvim wrapper's PATH.

For me, it makes sense that the plugins.lsp API had some minor tweaks and corrections to nvim-lspconfig's configs. But with lsp and plugins.lspconfig split, I'm not sure where such corrections would belong.

Keep in mind that the lsp module can be used without nvim-lspconfig if someone wants to configure the servers from scratch without the pre-defined configs.

I could see a case to be made for adding some fixes to pugins.lspconfig, so when enabled it creates some definitions in lsp.servers.<name>. I could also see a case to be made for adding some optional pre-defined configs to the lsp module, but this would have to be done in a way that makes sense with or without nvim-lspconfig.

We also have to consider the maintenance burden. We don't want to be responsible for ensuring every single lsp server has a working pre-defined config in nixvim (that's supposed to be nvim-lspconfig's job).

TL;DR: we haven't really thought about this much yet, and are open to ideas and brainstorming.

[jfly]

We don't want to be responsible for ensuring every single lsp server has a working pre-defined config in nixvim (that's supposed to be nvim-lspconfig's job).

Exactly. AFAIK, this quirky dependency of vue_ls on an enabled (and non-default configuration) of tl_ls is not something expressible in nvim-lspconfig. I suppose we could ask upstream if that's something they intend to be able to support.

I personally really enjoy it when nixos modules (and nixvim) go above and beyond to capture these quirky dependencies (the code y'all have for volar.tslsIntegration is a really beautiful example of what can be done with the nix module system). But I do understand that this is a maintenance burden. If it counts for anything as a user of nixvim: I'd prefer that nixvim try to have a working pre-defined config for everything, and it's on your community to be understanding when things break and to help keep things working.

But with lsp and plugins.lspconfig split, I'm not sure where such corrections would belong.

I'd propose a new plugins.lspconfig-quirks that we maintain here.

[MattSturgeon]

I think we have two main categories of custom behaviour in plugins.lsp.

We have things that are fundamental to the specific lsp server, like an option to install its package or related packages (e.g. rustc is one, iirc). We've already ported package to the new module, and I don't see why more bespoke "related but necessary" package options couldn't also be ported.

And we also have things that layer onto nvim-lspconfig. Maybe 5 or 6 servers have what we call customCmd, which is just a default definition for the server's cmd; effectively overriding nvim-lspconfig's cmd. If ported to the new system, this kinda thing should live as options under plugins.lspconfig.

Integration between servers, or with plugins, fall into a bit of an odd case. I suspect most of them assume they are layering on top of nvim-lspconfig. However many could probably also be made to work without nvim-lspconfig. A few may even work better without nvim-lspconfig; there are a handful of plugins that configure a server themselves and conflict with nvim-lspconfig.

Ideally, we'd want these integrations to handle all possible permutations. In most cases that would just mean checking config.plugins.lspconfig.enable.