Choose Elixir Language Server

[ankhers]

There are multiple language servers in the Elixir ecosystem. This will allow the user to select which they want to use, with the option of using more than one.

[sandydoo]

I wonder if we should make languageServer a nullOr package? People can then use their own package if needed. The example can mention the LSPs available.

I don't remember if there was an issue about this, but we were thinking about standardising how we set up LSPs for languages. Something like languageServer.enable, languageServer.package, and so on. Doesn't matter now, just some food for thought.

[domenkozar]

@ankhers maybe we can do something like @sandydoo suggested:

{
  languages.elixir.lsp.enable = true;
  languages.elixir.lsp.package = "lexical";
}

Where package would be an enum or types.package

[ankhers]

I'm not sure this is the best option. I'm not sure about other languages, but Elixir has multiple LSPs that can be used together. For example, there are ElixirLS and Lexical, which are the "big" main LSPs in the ecosystem.You would likely not use these together. But there is also https://github.com/elixir-tools/credo-language-server, which is a language server for credo, which is a linter within the ecosystem. If you use ElixirLS, you may want to use the credo LS with it. However, Lexical has this built in, so you (probably) would not gain anything from using Lexical with the credo LS.

[ankhers]

Just to add to this, especially if you had something like languages.elixir.lsp.package being types.package, I'm not sure what you get over just packages = [ pkgs.lexical ]. At least specifying the packages you could define multiple LSPs that could be used.

Also, some people may prefer to use ElixirLS, while others may prefer to use Lexical. I realize that you could just have a devnev.local.nix that specifies differences, but it is also easier to just enable things by default, and for the people that care about the disk space, they can explicitly remove things as needed.

[domenkozar]

I'm not sure it makes sense to make the API complicated for the use case of running two LSP for a language.

types.package is there so that you can override the package if you need to, otherwise "lexical" would work to (and we should decide on a default).