zed icon indicating copy to clipboard operation
zed copied to clipboard

Tracking Issue: Language Server Selection

Open maxdeviant opened this issue 2 years ago • 14 comments

This is a tracking issue for adding support for selecting which language servers should run for a given language.

Problem

Today, language servers in Zed are always run when installed and a buffer is opened with a language that has one or more registered language servers.

This can create issues with language servers conflicting with one another when multiple language servers are running for the same language.

There are also cases where a user may want to use an existing language server—provided by Zed or by an extension—with a language that is not registered for use with that language server.

Finally, there are cases where a user may want to disable the use of a particular language server entirely if they do not want to use it.

User Stories

  • User A wants to use the Biome language server instead of the built-in TypeScript and ESLint language servers.
  • User B wants to choose between two different language servers available for Elixir.
  • User C wants to use the toml extension for TOML syntax highlighting, but does not want to use the taplo language server.
  • User D wants to use the Tailwind language server with ASP.NET Razor pages (*.cshtml).

Proposed Solution

To provide Zed users with the ability to customize which language servers are run, we propose a new language_servers field under a given language's settings:

{
  "languages": {
    "TypeScript": {
      "language_servers": ["biome", "!typescript-language-server", "..."]
    }
  }
}

The language_servers field would be an array consisting of strings corresponding to the IDs of language servers.

In addition to specific language server IDs, the following additional syntax would be supported:

  • "!<language-server-id>" - Language server IDs may optionally be prefixed with a ! to remove the specified language server from consideration.
    • For example, "!typescript-language-server" would disable the typescript-language-server for the given language.
  • "..." - A placeholder to refer to the rest of the registered language servers for a given language.
    • This list would not contain any language servers that have already been referenced, e.g., if the set of all available language servers is ["a", "b", "c"] and the language_servers field contains ["!a", "..."] then "..." would expand to just ["b", "c"].

The introduction of the language_servers setting would supersede the following partial solutions we currently have in place to address these issues in a non-general fashion:

  • The elixir.lsp setting
    • This is currently used to choose between language servers to use with Elixir.
  • The deno.enable setting
    • This is currently used to toggle between using Deno over the built-in typescript-language-server and eslint.

User Stories

User A wants to use the Biome language server instead of the built-in TypeScript and ESLint language servers.

User A would add the following to their settings to use the Biome language server for their .ts and .tsx files:

{
  "languages": {
    "TypeScript": {
      "language_servers": ["biome", "!typescript-language-server", "!eslint", "..."]
    },
    "TSX": {
      "language_servers": ["biome", "!typescript-language-server", "!eslint", "..."]
    }
  }
}

User B wants to choose between two different language servers available for Elixir.

Zed currently offers two language servers for Elixir: elixir-ls and next-ls. elixir-ls is currently used by default.

If User B wants to prefer next-ls over elixir-ls they can do:

{
  "languages": {
    "Elixir": {
      "language_servers": ["next-ls", "..."]
    }
  }
}

This would give next-ls precedence over elixir-ls due to being first in the list. If User B wants to disable elixir-ls entirely (to prevent it from running at all), they could do:

{
  "languages": {
    "Elixir": {
      "language_servers": ["elixir-ls", "!next-ls", "..."]
    }
  }
}

User C wants to use the toml extension for TOML syntax highlighting, but does not want to use the taplo language server.

User C would add the following to their language settings to disable the taplo language server for TOML files:

{
  "languages": {
    "TOML": {
      "language_servers": ["!taplo", "..."]
    }
  }
}

User D wants to use the Tailwind language server with ASP.NET Razor pages (*.cshtml).

User D would add the following to their language settings to enable Zed's built-in Tailwind language server for their Razor files:

{
  "languages": {
    "Razor": {
      "language_servers": ["...", "tailwindcss-language-server"]
    }
  }
}

Steps

  • [x] Add language_servers setting for customizing which language servers should run (https://github.com/zed-industries/zed/pull/10911)
  • [x] Extract Deno support into an extension (https://github.com/zed-industries/zed/pull/10912)
  • [x] Extract Elixir support into an extension (https://github.com/zed-industries/zed/pull/10948)
  • [x] Allow controlling tailwindcss-language-server with language_servers setting (https://github.com/zed-industries/zed/pull/11012)
  • [ ] Allow extensions to provide a default language_servers settings for languages

Related Issues

Biome

  • https://github.com/biomejs/biome-zed/issues/5
  • https://github.com/biomejs/biome-zed/issues/10
  • https://github.com/zed-industries/zed/issues/10786

Deno

  • https://github.com/zed-industries/zed/issues/10169
  • https://github.com/zed-industries/zed/issues/10585

Elixir

  • https://github.com/zed-industries/zed/issues/8148
  • https://github.com/zed-industries/zed/issues/8129
  • https://github.com/zed-industries/zed/issues/4511
  • https://github.com/zed-industries/zed/issues/4732

Ruby

  • https://github.com/zed-industries/zed/issues/4834

maxdeviant avatar Apr 23 '24 19:04 maxdeviant

@maxdeviant I have a LSP usecase and would like to know if this should work at the moment, of after the language server selection feature.

I want to add ruff-lsp for formatting & linting, and some code actions (#4539). But I also want to keep pyright for the rest.

Would this work? I would expect diagnostics & code actions to come from both language servers

syphar avatar Apr 24 '24 06:04 syphar

Tried to use a different Python LSP, but this does not work

  "languages": {
    "Python": {
      "language_servers": ["pylsp", "!pyright"]
    }
  }

failable avatar Apr 25 '24 00:04 failable

I tried killing pyright without luck too.

"languages": {
  "Python": {
    "language_servers": ["ruff-lsp", "pylsp", "!pyright"]
  }
}

drcongo avatar Apr 25 '24 12:04 drcongo

I tried killing pyright without luck too.

"languages": {
  "Python": {
    "language_servers": ["ruff-lsp", "pylsp", "!pyright"]
  }
}

my understanding is that before lsp selection, each lsp has to be provided by the zed-core or an extension. And I don't see any ruff-lsp or pylsp extensions yet.

For python I could also imagine the python extension (when it's extracted) can select the LSP based on a setting?

syphar avatar Apr 25 '24 12:04 syphar

my understanding is that before lsp selection, each lsp has to be provided by the zed-core or an extension. And I don't see any ruff-lsp or pylsp extensions yet.

Correct, that is the case for now.

It would be nice to be able to register arbitrary language servers simply by creating an entry for them under "lsp" and providing a path to a local binary. And then add them to the list of servers to be used for individual languages.

jansol avatar Apr 25 '24 13:04 jansol

Would be nice to be able to see somewhere in the ui the running language servers

cholwell avatar Apr 25 '24 13:04 cholwell

It would be nice to be able to register arbitrary language servers simply by creating an entry for them under "lsp" and providing a path to a local binary. And then add them to the list of servers to be used for individual languages.

Looking at the extension API there also has to be some custom conversion logic for every LSP, so not sure if we can get around writing an extension for each of them.

Still, especially with python, having multiple active servers is not unusual / needed. Or using pylsp, which supports extensions

syphar avatar Apr 25 '24 14:04 syphar

my understanding is that before lsp selection, each lsp has to be provided by the zed-core or an extension. And I don't see any ruff-lsp or pylsp extensions yet.

Correct, that is the case for now.

It would be nice to be able to register arbitrary language servers simply by creating an entry for them under "lsp" and providing a path to a local binary. And then add them to the list of servers to be used for individual languages.

I don't think we're going to support this (at least, there are no plans to as part of this work).

As @syphar notes:

Looking at the extension API there also has to be some custom conversion logic for every LSP, so not sure if we can get around writing an extension for each of them.

Right now the intent is that any language servers should be provided by extensions.

maxdeviant avatar Apr 25 '24 15:04 maxdeviant

Would be nice to be able to see somewhere in the ui the running language servers

You can see a list of the currently running language servers in debug: open language server logs:

Screenshot 2024-04-25 at 11 15 06 AM

maxdeviant avatar Apr 25 '24 15:04 maxdeviant

when having multiple LSP it would be cool to be able to configure which to use for which use-case:

  • for formatting it's probably enough to select one
  • for diagnostics I would like to have multiple sources
  • same for code actions

not for my current use-case, but generally I could also imagine having multiple servers for autocompletions.

syphar avatar Apr 25 '24 15:04 syphar

@maxdeviant Hi, is there a plan to extract the solargraph (LSP) for Ruby? There is an issue regarding adding support for the Ruby LSP. I was considering writing an extension for it, but upon finding this issue, I thought it would be better to ask before. As far as I understand, extracting the solargraph LSP could serve as a good starting point for integrating Ruby LSP into the same extension, similar to what was done for the Elixir language in https://github.com/zed-industries/zed/pull/10948. So, Is it okay if I start working on extracting the solargraph gem into an extension as the starting point?

vitallium avatar Apr 26 '24 14:04 vitallium

@maxdeviant Hi, is there a plan to extract the solargraph (LSP) for Ruby? There is an issue regarding adding support for the Ruby LSP. I was considering writing an extension for it, but upon finding this issue, I thought it would be better to ask before. As far as I understand, extracting the solargraph LSP could serve as a good starting point for integrating Ruby LSP into the same extension, similar to what was done for the Elixir language in #10948. So, Is it okay if I start working on extracting the solargraph gem into an extension as the starting point?

If you'd like to start on extracting the Ruby support into an extension (we can keep it in the extensions/ directory in the Zed repo, for now), that would be great!

maxdeviant avatar May 01 '24 13:05 maxdeviant

Maybe related: https://github.com/zed-industries/zed/issues/11288

luckydye avatar May 02 '24 05:05 luckydye

@maxdeviant

@maxdeviant Hi, is there a plan to extract the solargraph (LSP) for Ruby? There is an issue regarding adding support for the Ruby LSP. I was considering writing an extension for it, but upon finding this issue, I thought it would be better to ask before. As far as I understand, extracting the solargraph LSP could serve as a good starting point for integrating Ruby LSP into the same extension, similar to what was done for the Elixir language in #10948. So, Is it okay if I start working on extracting the solargraph gem into an extension as the starting point?

If you'd like to start on extracting the Ruby support into an extension (we can keep it in the extensions/ directory in the Zed repo, for now), that would be great!

Awesome, I created a pull request here https://github.com/zed-industries/zed/pull/11360. Thanks!

vitallium avatar May 06 '24 10:05 vitallium

ruff-lsp will be superseded by ruff server for Python LSP implementation. Is there a plan to support that as well?

trickster avatar Jun 04 '24 10:06 trickster

ruff-lsp will be superseded by ruff server for Python LSP implementation. Is there a plan to support that as well?

That just means that the way to launch the LSP changes, should be easy to account for. And given that ruff is not supported at all yet the new way should probably be the one that is implemented (first, or even only)

jansol avatar Jun 04 '24 10:06 jansol

Is there any way for me to see what are the valid language server ids available for me to use currently?

tashi21 avatar Jun 14 '24 08:06 tashi21

Another use case: it would be very helpful to be able to select which language server to use on a per-file or per-folder basis.

I have a number of projects which use both Deno and Typescript within different folders of the same repo, and I need the correct language server to be used for each file.

tobico avatar Sep 03 '24 01:09 tobico