zed-industries / zed

Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
https://zed.dev
Other
50.51k stars 3.13k forks source link

Tracking Issue: Language Server Selection #10906

Open maxdeviant opened 7 months ago

maxdeviant commented 7 months ago

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

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:

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:

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

Related Issues

Biome

Deno

Elixir

Ruby

syphar commented 7 months ago

@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

failable commented 7 months ago

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

  "languages": {
    "Python": {
      "language_servers": ["pylsp", "!pyright"]
    }
  }
drcongo commented 7 months ago

I tried killing pyright without luck too.

"languages": {
  "Python": {
    "language_servers": ["ruff-lsp", "pylsp", "!pyright"]
  }
}
syphar commented 7 months ago

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?

jansol commented 7 months ago

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.

cholwell commented 7 months ago

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

syphar commented 7 months ago

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

maxdeviant commented 7 months ago

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 commented 7 months ago

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
syphar commented 7 months ago

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

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

vitallium commented 7 months ago

@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?

maxdeviant commented 6 months ago

@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!

luckydye commented 6 months ago

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

vitallium commented 6 months ago

@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!

trickster commented 5 months ago

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

jansol commented 5 months ago

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)

tashi21 commented 5 months ago

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

tobico commented 2 months ago

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.

injust commented 2 months ago

This syntax is really confusing to me. I understand that this handles some advanced scenarios, but it seems like you've introduced a tri-state for something that is conventionally a boolean.

What's the difference between ["foo", "bar"] and ["foo", "bar", "!baz"]?

Does "..." mean "any language server that is installed but not present in the array becomes implicitly enabled"?