Before, inlay chunks were retrieved from the cache based on actualized
anchor ranges, but using an old buffer snapshot. Now, update all chunks
and snapshot to the actual before returning the applicable ones.
Follow-up of https://github.com/zed-industries/zed/pull/40183
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/40047
Closes https://github.com/zed-industries/zed/issues/24798
Closes https://github.com/zed-industries/zed/issues/24788
Before, each editor, even if it's the same buffer split in 2, was
querying for inlay hints separately, and storing the whole inlay hint
twice, in `Editor`'s `display_map` and its `inlay_hint_cache` fields.
Now, instead of `inlay_hint_cache`, each editor maintains a minimal set
of metadata (which area was queried by what task) instead, and all LSP
inlay hint data had been moved into `LspStore`, both local and remote
flavors store the data.
This allows Zed, as long as a buffer is open, to reuse the inlay hint
data similar to how document colors and code lens are now stored and
reused.
Unlike other reused LSP data, inlay hints data is the first one that's
possible to query by document ranges and previous version had issue with
caching and invalidating such ranges already queried for.
The new version re-approaches this by chunking the file into row ranges,
which are queried based on the editors' visible area.
Among the corresponding refactoring, one notable difference in inlays
display are multi buffers: buffers in them are not
[registered](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didOpen)
in the language server until a caret/selection is placed inside their
excerpts inside the multi buffer.
New inlays code does not query language servers for unregistered
buffers, as servers usually respond with empty responses or errors in
such cases.
Release Notes:
- Reworked inlay hints to be less error-prone
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: dino <dinojoaocosta@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
When running flycheck, I've noticed that scrolling starts to lag:
https://github.com/user-attachments/assets/b0bef0a3-ccbd-479d-a385-273398086d38
When checking the trace, it is notable that project panel updates its
entire tree multiple times during flycheck:
<img width="2032" height="1136" alt="image"
src="https://github.com/user-attachments/assets/d1935e77-3b00-4be5-a12a-8a17a9d64202"
/>
[scrolling.trace.zip](https://github.com/user-attachments/files/22710852/scrolling.trace.zip)
Turns out, `target/debug` directory is loaded by Zed (presumably,
reported by langserver as there are sources generated by bindgen and
proto that need to be loaded), and `target/debug/build` directory
received multiple events of a `None` kind for Zed, which trigger the
rescans.
Rework the logic to omit the `None`-kind events in Zed, and to avoid
excessive repo updates if not needed.
Release Notes:
- Improved worktree FS event emits in gitignored directories
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Add tests on task commands, to ensure things like
https://github.com/zed-industries/zed/issues/38343 do not come so easily
unnoticed and to provide a base to create more tests in the future, if
needed.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Follow-up of https://github.com/zed-industries/zed/pull/37352
Closes https://github.com/zed-industries/zed/issues/37132
* disabled word completions in the agent panel's editor
* if not disabled, allow to trigger word completions with an action even
if the completions threshold is not reached
Release Notes:
- Fixed word completions appearing in the agent panel's editor and not
appearing when triggered with the action before the completion threshold
is reached
Closes https://github.com/zed-industries/zed/issues/37144
Adjusts `editor::DeleteToPreviousWordStart`,
`editor::DeleteToNextWordEnd`, `editor::DeleteToNextSubwordEnd` and
`editor::DeleteToPreviousSubwordStart` actions to
* take whitespace sequences with length >= 2 into account and stop after
removing them (whilst movement would also include the word after such
sequences)
* take current language's brackets into account and stop after removing
the text before them
The latter is configurable and can be disabled with `"ignore_brackets":
true` parameter in the action.
Release Notes:
- Improved word deletions to consider whitespace sequences and brackets
by default
Follow-up of https://github.com/zed-industries/zed/pull/36764
* Fix `anyhow!({e})` conversion lossing Collab error codes context when
opening a buffer remotely
* Use this context to only allow opening files that had not specific
Collab error code
Release Notes:
- N/A
Follow-up https://github.com/zed-industries/zed/pull/37083
Noisy RPC LSP logs were functioning this way already, but to keep Collab
loaded even less, do not send any kind of logs to the client if the
client has a corresponding log tab not opened.
This change is pretty raw and does not fully cover scenarious with
multiple clients: if one client has a log tab open and another opens tab
with another kind of log, the 2nd kind of logs will be streamed only.
Also, it should be possible to forward the host logs to the client on
enabling — that is not done to keep the change smaller.
Release Notes:
- N/A
Take 2: https://github.com/zed-industries/zed/pull/36709 but without the
very bad `cfg`-based approach for storing the RPC logs.
--------------
Enables LSP log tracing in both remote collab and remote ssh
environments.
Server logs and server RPC traces can now be viewed remotely, and the
LSP button is now shown in such projects too.
Closes https://github.com/zed-industries/zed/issues/28557
Co-Authored-By: Kirill <kirill@zed.dev>
Co-Authored-By: Lukas <lukas@zed.dev>
Release Notes:
- Enabled LSP log tracing in both remote collab and remote ssh
environments
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Removes `diagnostics.cargo.fetch_cargo_diagnostics` settings as those
are not needed for the flycheck diagnostics to run.
This setting disabled `checkOnSave` in rust-analyzer and allowed to
update diagnostics via flycheck in the project diagnostics editor with
the "refresh" button.
Instead, `"checkOnSave": false,` can be set manually as
https://zed.dev/docs/languages/rust#more-server-configuration example
shows and flycheck commands can be called manually from anywhere,
including the diagnostics panel, to refresh the diagnostics.
Release Notes:
- Removed redundant `diagnostics.cargo.fetch_cargo_diagnostics` settings
Flycheck commands are global and makes sense to fall back to looking up
project's rust-analyzer even if the commands are run on a non-rust
buffer. If multiple rust-analyzers are found in the project, avoid
ambiguous commands and bail (as before).
Closes #ISSUE
Release Notes:
- Made it possible to run rust-analyzer's flycheck actions from anywhere
in the project
Introduce `min_words_query_len` threshold for automatic word completion
display, and set it to 3 by default.
Re-enable word completions in Markdown and Plaintext.
Release Notes:
- Introduced `min_words_query_len` threshold for automatic word
completion display, and set it to 3 by default to make them less
intrusive
Instead of holding a connection for potentially long LSP queries (e.g.
rust-analyzer might take minutes to look up a definition), disconnect
right after sending the initial request and handle the follow-up
responses later.
As a bonus, this allows to cancel previously sent request on the local
Collab clients' side due to this, as instead of holding and serving the
old connection, local clients now can stop previous requests, if needed.
Current PR does not convert all LSP requests to the new paradigm, but
the problematic ones, deprecating `MultiLspQuery` and moving all its
requests to the new paradigm.
Release Notes:
- Improved resource usage when querying LSP over Collab
---------
Co-authored-by: David Kleingeld <git@davidsk.dev>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: David Kleingeld <davidsk@zed.dev>
Diagnostics updates were programmed in Zed based off the r-a LSP push
diagnostics, with all related updates happening per file.
https://github.com/zed-industries/zed/pull/19230 and especially
https://github.com/zed-industries/zed/pull/32269 brought in pull
diagnostics that could produce results for thousands files
simultaneously.
It was noted and addressed on the local side in
https://github.com/zed-industries/zed/pull/34022 but the remote side was
still not adjusted properly.
This PR
* removes redundant diagnostics pull updates on remote clients, as
buffer diagnostics are updated via buffer sync operations separately
* batches all diagnostics-related updates and proto messages, so
multiple diagnostic summaries (per file) could be sent at once,
specifically, 1 (potentially large) diagnostics summary update instead
of N*10^3 small ones.
Buffer updates are still sent per buffer and not updated, as happening
separately and not offending the collab traffic that much.
Release Notes:
- Improved diagnostics performance in the collaborative mode
* Straightens out the `*_ext.rs` workflow for clangd and rust-analyzer:
no need to asynchronously query for the language server, as we sync that
information already.
* Fixes inlay hints editor menu toggle not being shown in the remote
sessions
Release Notes:
- Fixed inlay hints editor menu toggle not being shown in the remote
sessions
Before, each time any LSP feature was used on client remote, it always
produced a `proto::` request that always had been sent to the host, from
where returned as an empty response.
Instead, propagate more language server-related data to the client,
`lsp::ServerCapability`, so Zed client can omit certain requests if
those are not supported.
On top of that, rework the approach Zed uses to query for the data
refreshes: before, editors tried to fetch the data when the server start
was reported (locally and remotely).
Now, a later event is selected: on each `textDocument/didOpen` for the
buffer contained in this editor, we will query for new LSP data, reusing
the cache if needed.
Before, servers could reject unregistered files' LSP queries, or process
them slowly when starting up.
Now, such refreshes are happening later and should be cached.
This requires a collab DB change, to restore server data on rejoin.
Release Notes:
- Fixed excessive LSP requests sent during remote sessions
As reported [in
Discord](https://discord.com/channels/869392257814519848/1106226198494859355/1398470747227426948)
C projects with `"` as "brackets" that autoclose, may invoke panics when
edited at the end of the file.
With a single selection-caret (`ˇ`), at the end of the file,
```c
ifndef BAR_H
#define BAR_H
#include <stdbool.h>
int fn_branch(bool do_branch1, bool do_branch2);
#endif // BAR_H
#include"ˇ"
```
gets an LSP response from clangd
```jsonc
{
"filterText": "AGL/",
"insertText": "AGL/",
"insertTextFormat": 1,
"kind": 17,
"label": " AGL/",
"labelDetails": {},
"score": 0.78725427389144897,
"sortText": "40b67681AGL/",
"textEdit": {
"newText": "AGL/",
"range": { "end": { "character": 11, "line": 8 }, "start": { "character": 10, "line": 8 } }
}
}
```
which replaces `"` after the caret (character/column 11, 0-indexed).
This is reasonable, as regular follow-up (proposed in further
completions), is a suffix + a closing `"`:
<img width="842" height="259" alt="image"
src="https://github.com/user-attachments/assets/ea56f621-7008-4ce2-99ba-87344ddf33d2"
/>
Yet when Zed handles user input of `"`, it panics due to multiple
reasons:
* after applying any snippet text edit, Zed did a selection change:
https://github.com/zed-industries/zed/blob/55379876301bd4dcfe054a146b66288d2e60a523/crates/editor/src/editor.rs#L9539-L9545
which caused eventual autoclose region invalidation:
https://github.com/zed-industries/zed/blob/55379876301bd4dcfe054a146b66288d2e60a523/crates/editor/src/editor.rs#L2970
This covers all cases that insert the `include""` text.
* after applying any user input and "plain" text edit, Zed did not
invalidate any autoclose regions at all, relying on the "bracket" (which
includes `"`) autoclose logic to rule edge cases out
* bracket autoclose logic detects previous `"` and considers the new
user input as a valid closure, hence no autoclose region needed.
But there is an autoclose bracket data after the plaintext completion
insertion (`AGL/`) really, and it's not invalidated after `"` handling
* in addition to that, `Anchor::is_valid` method in `text` panicked, and
required `fn try_fragment_id_for_anchor` to handle "pointing at odd,
after the end of the file, offset" cases as `false`
A test reproducing the feedback and 2 fixes added: proper, autoclose
region invalidation call which required the invalidation logic tweaked a
bit, and "superficial", "do not apply bad selections that cause panics"
fix in the editor to be more robust
Release Notes:
- Fixed panic with completion ranges and autoclose regions interop
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Follow-up of https://github.com/zed-industries/zed/pull/34208
Closes https://github.com/zed-industries/zed/issues/35185
Previous code assumed that extensions' language server wrappers may leak
only in static data (e.g. fields that were not cleared on deinit), but
we seem to have a race that breaks this assumption.
1. We do clean `all_lsp_adapters` field after
https://github.com/zed-industries/zed/pull/34334 and it's called for
every extension that is unregistered.
2. `LspStore::maintain_workspace_config` ->
`LspStore::refresh_workspace_configurations` chain is triggered
independently, apparently on `ToolchainStoreEvent::ToolchainActivated`
event which means somewhere behind there's potentially a Python code
that gets executed to activate the toolchian, making
`refresh_workspace_configurations` start timings unpredictable.
3. Seems that toolchain activation overlaps with plugin reload, as
`2025-07-28T12:16:19+03:00 INFO [extension_host] extensions updated.
loading 0, reloading 1, unloading 0` suggests in the issue logs.
The plugin reload seem to happen faster than workspace configuration
refresh in
https://github.com/zed-industries/zed/blob/c65da547c9aa5d798a1a71468bf253bf55d1cb09/crates/project/src/lsp_store.rs#L7426-L7456
as the language servers are just starting and take extra time to respond
to the notification.
At least one of the `.clone()`d `adapter`s there is the adapter that got
removed during plugin reload and has its channel closed, which causes a
panic later.
----------------------------
A good fix would be to re-architect the workspace refresh approach, same
as other accesses to the language server collections.
One way could be to use `Weak`-based structures instead, as definitely
the extension server data belongs to extension, not the `LspStore`.
This is quite a large undertaking near the extension core though, so is
not done yet.
Currently, to stop the excessive panics, no more `.expect` is done on
the channel result, as indeed, it now can be closed very dynamically.
This will result in more errors (and backtraces, presumably) printed in
the logs and no panics.
More logging and comments are added, and workspace querying is replaced
to the concurrent one: no need to wait until a previous server had
processed the notification to send the same to the next one.
Release Notes:
- Fixed warm-related panic happening during startup
Follow-up of https://github.com/zed-industries/zed/pull/33417
* adjust prettier mock LSP to handle `shutdown` and `exit` messages
* removed another `?.log_err()` backtrace from logs and improved the
logging info
* always handle the last parts of the shutdown logic even if the
shutdown response had failed
Release Notes:
- N/A
Fixes an issue that caused Windows to fail when removing extension's
directories, as Zed had never stop any related processes.
Now:
* Zed shuts down and waits until the end when the language servers are
shut down
* Adds `impl Drop for WasmExtension` where does
`self.tx.close_channel();` to stop a receiver loop that holds the "lock"
on the extension's work dir.
The extension was dropped, but the channel was not closed for some
reason.
* Does more unregistration to ensure `Arc<WasmExtension>` with the `tx`
does not leak further
* Tidies up the related errors which had never reported a problematic
path before
Release Notes:
- N/A
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Smit <smit@zed.dev>
When navigating back in the context menu, it was not possible to get
past first element, if it was not selectable.
The other way around works, hence the fix.
Release Notes:
- N/A
* Add a "close item"-like binding to close the active dock, if present
Now, cmd/ctrl-w can be used close the focused dock before the Zed window
* Add defaults to MoveItem* actions to make it appear in the command
palette
Release Notes:
- N/A
Stop doing useless prettier-related work when doing a project search.
Before, project search might cause
<img width="1728" alt="not_pretty"
src="https://github.com/user-attachments/assets/5f8b935f-962d-488e-984f-50dfbaee97ba"
/>
but now we debounce the prettier-related task first, and actually set
the "installed" state for the default prettier, when there's no install
needed.
Release Notes:
- N/A
This reverts commit 1edaeebae5.
Based on an elevated number of ESLint-related issues, reverting the
upgrade.
Many people upvoted the issues and did not share any repro details, so
cannot be certain what's more broken: seems relatively generic as
related to *.ts ESLint configs.
Checked the revert on 2 projects from the issues below:
Closes https://github.com/zed-industries/zed/issues/33425
With https://github.com/adamhl8/zed-33425 as an example repo: there,
both eslint configurations worked for me when I stopped Zed and opened a
project.
Somehow, switching various Zed's with different vscode-eslint package
versions, eventually I get
`Error: Cannot find module
'~/.local/share/zed/languages/eslint/vscode-eslint-3.0.10/vscode-eslint/server/out/eslintServer.js'`-ish
error.
Not very related to issues with newer vscode-eslint integration, but
worth mentioning as is related to the package updates.
Closes https://github.com/zed-industries/zed/issues/33648
With a good example of
https://github.com/florian-lackner365/zed-eslint-bug monorepo project.
The monorepo part seems not to be related, but somehow,
`eslint.config.js` is involved as the newer vscode-eslint fails to find
a config.
Works well with the older vscode-eslint.
Release Notes:
- Downgraded to vscode-eslint-2.4.4 as a ESLint language server
Closes https://github.com/zed-industries/zed/issues/33575
* Fixes inlay colors spoiled after document color displayed
* Optimizes the query pattern for large multi buffers
Release Notes:
- Fixed document colors issues with other inlays and multi buffers
Kirill Bulatov
