Release Notes:
- Prevents the terminal from opening on release mode on Windows
Note: this also prevents Zed from logging to the terminal when it is
launched from the terminal. Is this expected behaviour on other
platforms?
---------
Co-authored-by: 白山風露 <shirayama.kazatsuyu@gmail.com>
Most notably, this should do away with completions overriding the whole
word around completion trigger text. Fixes: #4816
Release Notes:
- Fixed code completions overriding text around the cursor.
Follow-up of https://github.com/zed-industries/zed/pull/8874 and
https://github.com/zed-industries/zed/pull/7635
Closes https://github.com/zed-industries/zed/issues/7609
* mentions all `lsp::CodeActions` properties in the Zed client resolve
capabilities to remove more json out of general actions request
potentially
* removes odd `CodeActions.data` field checks, as that field is opaque
and is intended to store data, needed by the langserver to resolve this
code action
* if any `CodeAction` lacks either `command` or `edits` fields, tries to
resolve the action
This all effectively causes Zed to always fire an action resolve
request, since we update actions list (replacing the resolved actions
with the new, unresolved ones) via `refresh_code_actions`
9e66d48ccd/crates/editor/src/editor.rs (L3650)
that is being called on selections change and the actions menu open.
Yet, we do not query the resolve until the action is either applied
(selected in the list), or called for formatting, so it seems to be fine
to resolve them always, as it's not a frequent operation such as
reacting to every keystroke.
Release Notes:
- Fixed certain code actions not being resolved properly ([7609](https://github.com/zed-industries/zed/issues/7609))
---------
Co-authored-by: Derrick Laird <swampdonk@gmail.com>
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
This PR adds **internal** ability to run arbitrary language servers via
WebAssembly extensions. The functionality isn't exposed yet - we're just
landing this in this early state because there have been a lot of
changes to the `LspAdapter` trait, and other language server logic.
## Next steps
* Currently, wasm extensions can only define how to *install* and run a
language server, they can't yet implement the other LSP adapter methods,
such as formatting completion labels and workspace symbols.
* We don't have an automatic way to install or develop these types of
extensions
* We don't have a way to package these types of extensions in our
extensions repo, to make them available via our extensions API.
* The Rust extension API crate, `zed-extension-api` has not yet been
published to crates.io, because we still consider the API a work in
progress.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
After a lot of back-and-forth, this is a small attempt to implement
solutions (1) and (3) in
https://github.com/zed-industries/zed/issues/7902. The goal is to have a
minimal change that helps users get started with Zed, until we have
extensions ready.
Release Notes:
- Added detection of user-installed `gopls` to Go language server
adapter. If a user has `gopls` in `$PATH` when opening a worktree, it
will be used.
- Added detection of user-installed `zls` to Zig language server
adapter. If a user has `zls` in `$PATH` when opening a worktree, it will
be used.
Example:
I don't have `go` installed globally, but I do have `gopls`:
```
~ $ which go
go not found
~ $ which gopls
/Users/thorstenball/code/go/bin/gopls
```
But I do have `go` in a project's directory:
```
~/tmp/go-testing φ which go
/Users/thorstenball/.local/share/mise/installs/go/1.21.5/go/bin/go
~/tmp/go-testing φ which gopls
/Users/thorstenball/code/go/bin/gopls
```
With current Zed when I run `zed ~/tmp/go-testing`, I'd get the dreaded
error:
But with the changes in this PR, it works:
```
[2024-02-23T11:14:42+01:00 INFO language::language_registry] starting language server "gopls", path: "/Users/thorstenball/tmp/go-testing", id: 1
[2024-02-23T11:14:42+01:00 INFO language::language_registry] found user-installed language server for Go. path: "/Users/thorstenball/code/go/bin/gopls", arguments: ["-mode=stdio"]
[2024-02-23T11:14:42+01:00 INFO lsp] starting language server. binary path: "/Users/thorstenball/code/go/bin/gopls", working directory: "/Users/thorstenball/tmp/go-testing", args: ["-mode=stdio"]
```
---------
Co-authored-by: Antonio <antonio@zed.dev>
Before:
```
[2024-02-21T18:55:55+02:00 INFO language::language_registry] starting language server "eslint", path: "/Users/someonetoignore/Downloads/eslint-configs-demo", id: 2
[2024-02-21T18:55:56+02:00 INFO lsp] 2 unhandled notification window/logMessage:
{
"type": 3,
"message": "ESLint server running in node v18.15.0"
}
[2024-02-21T18:55:56+02:00 INFO lsp] 2 unhandled notification eslint/confirmESLintExecution:
{
"scope": "local",
"uri": "file:///Users/someonetoignore/Downloads/eslint-configs-demo/index.js",
"libraryPath": "/Users/someonetoignore/Downloads/eslint-configs-demo/node_modules/eslint/lib/api.js"
}
```
After:
```
[2024-02-21T18:57:31+02:00 INFO language::language_registry] starting language server "eslint", path: "/Users/someonetoignore/Downloads/eslint-configs-demo", id: 2
[2024-02-21T18:57:32+02:00 INFO lsp] Language server with id 2 sent unhandled notification window/logMessage:
{
"type": 3,
"message": "ESLint server running in node v18.15.0"
}
[2024-02-21T18:57:32+02:00 INFO project::prettier_support] Fetching default prettier and plugins: [("prettier-plugin-tailwindcss", "0.5.11"), ("prettier", "3.2.5")]
[2024-02-21T18:57:32+02:00 INFO lsp] Language server with id 2 sent unhandled notification eslint/confirmESLintExecution:
{
"scope": "local",
"uri": "file:///Users/someonetoignore/Downloads/eslint-configs-demo/index.js",
"libraryPath": "/Users/someonetoignore/Downloads/eslint-configs-demo/node_modules/eslint/lib/api.js"
}
```
We have to pass a name there too, but the problem here is that the
unhandled message callback is created very early, along with the binary,
but the server name is received from the LSP initialize response, which
is a totally separate piece of code.
I plan to refactor that code next, but so far, improve the logs at least
slightly.
Release Notes:
- N/A
This should help us debug more failures because we can now see what
exactly was started.
Release Notes:
- N/A
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Max <max@zed.dev>
Zed's LSP support expects request messages to have integer ID, Metals
LSP uses string. According to specification, both is acceptable:
interface RequestMessage extends Message {
/**
* The request id.
*/
id: integer | string;
...
This pull requests modifies the types and serialization/deserialization
so that string IDs are accepted.
Release Notes:
- Make Zed LSP request ids compliant to the LSP specification
The current LSP headers reader implementation assumes a specific order
(i.e., `Content-Length` first, and then `Content-Type`). Unfortunately,
this assumption is not always valid, as no specification enforces the
rule. @caius and I encountered this issue while implementing the
Terraform LSP, where `Content-Type` comes first, breaking the
implementation in #6929.
This PR introduces a `read_headers` function, which asynchronously reads
the incoming pipe until the headers' delimiter (i.e., '\r\n\r\n'),
adding it to the message buffer, and returning an error when delimiter's
not found.
I added a few tests but only considered scenarios where headers are
delivered at once (which should be the case?). I'm unsure if this
suffices or if I should consider more scenarios; I would love to hear
others' opinions.
Release Notes:
- N/A
---------
Co-authored-by: Caius <caius@caius.name>
Previously we would run these loops indefinitely when a language server
closed its stdout/stderr and the `read_until` returned `0` bytes read.
Easy to reproduce: start Zed with LSP attached, `kill -9` the LSP, see
logs accumulate.
Release Notes:
- Fix high CPU usage when a language server crashes (or closes its
stdout/stderr on purpose).
Co-authored-by: Julia <julia@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Based on the great work in
https://github.com/zed-industries/zed/pull/7130 , now sends this data
```
[crates/lsp/src/lsp.rs:588] ClientInfo { name: name.to_string(), version: Some(version.to_string()) } = ClientInfo {
name: "Zed Dev",
version: Some(
"0.122.0",
),
}
```
with every LSP server initialization.
Release Notes:
- Added Zed name and version to LSP InitializeParams requests
This PR sorts the dependency lists in our `Cargo.toml` files so that
they are in alphabetical order.
This should make them easier to visually scan when looking for a
dependency.
Apologies in advance for any merge conflicts 🙈
Release Notes:
- N/A
- [x] Fill in GPL license text.
- [x] live_kit_client depends on live_kit_server as non-dev dependency,
even though it seems to only be used for tests. Is that an issue?
Release Notes:
- N/A
Before this change, we would send requests to language servers without
canceling them even if we never wait for their response.
Example: when doing document highlights, we'd send a request (modulo
debouncing) whenever a change was made, ignoring previously sent
requests that might still be in-flight.
With this change, we now send a Cancel request (from the LSP spec) to
the language server in case no one listens to the response anymore
(which is what happens when the `Future` returned by `request_internal`)
is dropped.
Adding the typos crate to our CI will take some doing, as we have
several tests which rely on typos in various ways (e.g. checking state
as the user types), but I thought I'd take a first stab at fixing what
it finds.
Release Notes:
- N/A
This PR cleans up a handful of references in doc comments in the `lsp`
crate so that `rustdoc` will link and display them correctly.
Release Notes:
- N/A
This is a PR I built for a friend of a friend at StrangeLoop, who is
making a much better LSP for elixir that elixir folks want to experiment
with. This PR also improves the our debug log viewer to handle LSP
restarts.
TODO:
- [ ] Make sure NextLS binary loading works.
Release Notes:
- Added support for the experimental Next LS for Elxir, to enable it add
the following field to your settings to enable:
```json
"elixir": {
"next": "on"
}
```
Copilot sends multiple events about its LSP server readiness, not necessarily recreating the server from scratch (e.g. due to re-sign in action).
Avoid re-adding same log subscriptions on the same LSP server, which
causes panics.
