Closes #ISSUE
Adds `merge_message` field to the `UpdateRepository` proto message so
that suggested merge messages are displayed in remote projects.
Release Notes:
- git: Fixed an issue where suggested merge commit messages would not
appear for remote projects
I haven't found any issues related to this, but it seems like currently
the wrong directory is added to the path when spawning tasks on windows
with a python virtual environment. I also deduplicated the logic at a
few places. The same constant exists in the languages crate, but we
don't want to pull an additional dependency just for this.
-1 papercut
Release Notes:
- Fix python venv path when spawning tasks on windows
Follow-up of https://github.com/zed-industries/zed/pull/35306
This PR contains two changes:
Both changes are inspired from:
d90a87f955/client/src/common/textSynchronization.ts
1. Handling `textDocument/didSave` and `textDocument/didChange`
registration and unregistration correctly:
```rs
#[derive(Debug, Eq, PartialEq, Clone, Deserialize, Serialize)]
#[serde(untagged)]
pub enum TextDocumentSyncCapability {
Kind(TextDocumentSyncKind),
Options(TextDocumentSyncOptions),
}
```
- `textDocument/didSave` dynamic registration contains "includeText"
- `textDocument/didChange` dynamic registration contains "syncKind"
While storing this to Language Server, we use
`TextDocumentSyncCapability::Options` instead of
`TextDocumentSyncCapability::Kind` since it also include
[change](be7336e92a/src/lib.rs (L1714-L1717))
field as `TextDocumentSyncCapability::Kind` as well as
[save](be7336e92a/src/lib.rs (L1727-L1729))
field as `TextDocumentSyncSaveOptions`. This way while registering or
unregistering both of them, we don't accidentaly mess with other data.
So, if at intialization we end up getting
`TextDocumentSyncCapability::Kind` and we receive any above kind of
dynamic registration, we change `TextDocumentSyncCapability::Kind` to
`TextDocumentSyncCapability::Options` so we can store more data anyway.
2. Modify `include_text` method to only depend on
`TextDocumentSyncSaveOptions`, instead of depending on
`TextDocumentSyncKind`. Idea behind this is,
`TextDocumentSyncSaveOptions` should be responsible for
"textDocument/didSave" notification, and `TextDocumentSyncKind` should
be responsible for "textDocument/didChange", which it already is:
4b79eade1d/crates/project/src/lsp_store.rs (L7324-L7331)
Release Notes:
- N/A
- **WIP: reorganize dispositions**
- **Introduce a LocalToolchainStore trait and use it for LspAdapter
methods**
Closes#35782Closes#27331
Release Notes:
- Python: Improved propagation of a selected virtual environment into
the LSP configuration. This should the make all language-related
features such as Go to definition or Find all references more reliable.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
cc https://github.com/zed-industries/zed/issues/34666
Display printing anyhow errors only renders the error itself, but not
any of its causes so we've been dropping the important context when
showing the issue to the users.
Release Notes:
- N/A
Crux of the issue was that we were checking whether a venv activation
script exists on local filesystem, which is obviously wrong for remote
projects. This PR also does away with `source` for venv activation in
favor of `.`, which is compliant with `sh`
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Closes#34648
Release Notes:
- Python: fixed activation of virtual environments in terminals for
remote projects
Co-authored-by: Lukas Wirth <lukas@zed.dev>
This PR adds preliminary git clone support through using the new
`GitClone` action. This works with SSH connections too.
- [x] Get backend working
- [x] Add a UI to interact with this
Future follow-ups:
- Polish the UI
- Have the path select prompt say "Select Repository clone target"
instead of “Open”
- Use Zed path prompt if the user has that as a setting
- Add support for cloning from a user's GitHub repositories directly
Release Notes:
- Add the ability to clone remote git repositories through the `git:
Clone` action
---------
Co-authored-by: hpmcdona <hayden_mcdonald@brown.edu>
Settings overrides (e.g. local project settings, server settings) can no
longer change `disable_ai` to `false` if it was `true`; they can only
change it to `true`. In other words, settings can only cause AI to be
*more* disabled, they can't undo the user's preference for no AI (or the
project's requirement not to use AI).
Release Notes:
- Settings overrides (such as local project settings) can now only
override `disable_ai` to become `true`; they can no longer cause
otherwise-disabled AI to become re-enabled.
---------
Co-authored-by: Assistant <assistant@anthropic.com>
Co-authored-by: David Kleingeld <git@davidsk.dev>
Closes#34204
Adds the ability to dynamically register and unregister code actions for
language servers such as Biome.
See more:
https://github.com/zed-industries/zed/issues/34204#issuecomment-3134227856
Release Notes:
- Fixed an issue where the Biome formatter was always used even when
`require_config_file` was set to true and the project had no config
file.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
It's unfortunate to need to have access to a GPUI window in order to
create a terminal, because it forces to take a `Window` parameter in
entities that otherwise would have been pure models.
This pull request changes it so that we pass the `Project`'s entity id,
which is equally stable as the window id.
Release Notes:
- N/A
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
- **Use a struct instead of a thruple for visible worktree entries**
- **Try some telemetry**
Closes #ISSUE
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Just like with diagnostics, adding a configurable padding to inline
blame
Release Notes:
- Added configurable padding to inline blame
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
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
I also removed a debug assertion that wasn't true when a debug session
was restarting through a request, because there wasn't a booting task
Zed needed to run before the session.
I renamed SessionState::Building to SessionState::Booting as well,
because building implies that we're building code while booting the
session covers more cases and is more accurate.
Release Notes:
- debugger: Filter out more invalid debug configurations from the debug
picker
Co-authored-by: Remco Smits <djsmits12@gmail.com>
* 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
This is a bit of a readability improvement IMHO; I often find myself
confused when dealing when dimension pairs, as there's no easy way to
jump to the implementation of a dimension for tuples to remind myself
for the n-th time how exactly that impl works. Now it should be possible
to jump directly to that impl.
Another bonus is that Dimension supports 3-ary tuples as well - by using
a () as a default value of a 3rd dimension.
Release Notes:
- N/A
Release Notes:
- Edit Prediction: Added Git info to edit predictions requests (only
sent for opensource projects when data collection is enabled). The sent
Git info is the SHA of the current commit and the URLs for the `origin`
and `upstream` remotes.
Closes#33700
The option shows up as an icon that appears on entries that would create
a new branch. You can also branch from the default by secondary
confirming, which the icon has a tooltip for as well.
We based the default branch on the results from this command: `git
symbolic-ref refs/remotes/upstream/HEAD` and fallback to `git
symbolic-ref refs/remotes/origin/HEAD`
Release Notes:
- Add option to create a branch from a default branch in git branch
picker
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Even after #35327 edit predictions were still being queried and shown
after setting `"disable_ai": true`
Also moves `DisableAiSettings` to the `project` crate so that it gets
included in tests via existing use of `Project::init_settings(cx)`.
Release Notes:
- Fixed `"disable_ai": true` setting disabling edit predictions.
Closes#34094
Bug in https://github.com/zed-industries/zed/pull/11157
**Context:**
In https://github.com/zed-industries/zed/pull/31872, we added logic to
avoid re-querying language server completions
(`textDocument/completion`) when possible. This means the list of
`lsp::CompletionItem` objects we have might be stale and not contain
accurate data like `text_edit`, which is only valid for the buffer at
the initial position when these completions were requested. We don't
really care about this because we already extract all the useful data we
need (like insert/replace ranges) into `Completion`, which converts
`text_edit` to anchors. This means further user edits simply push/move
those anchors, and our insert/replace ranges persist for completion
accept.
```jsonc
// on initial textDocument/completion
"textEdit":{"insert":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}},"replace":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}}
```
However, for showing documentation of visible `Completion` items, we
need to call resolve (`completionItem/resolve`) with the existing
`lsp::CompletionItem`, which returns the same `text_edit` and other
existing data along with additional new data that was previously
optional, like `documentation` and `detail`.
**Problem:**
This new data like `documentation` and `detail` doesn't really change on
buffer edits for a given completion item, so we can use it. But
`text_edit` from this resolved `lsp::CompletionItem` was valid when the
the initial (`textDocument/completion`) was queried but now the
underlying buffer is different. Hence, creating anchors from this ends
up creating them in wrong places.
```jsonc
// calling completionItem/resolve on cached lsp::CompletionItem results into same textEdit, despite buffer edits
"textEdit":{"insert":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}},"replace":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}}
```
It looks like the only reason to override the new text and these ranges
was to handle an edge case with `typescript-language-server`, as
mentioned in the code comment. However, according to the LSP
specification for [Completion
Request](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_completion):
> All other properties (usually sortText, filterText, insertText and
textEdit) must be provided in the textDocument/completion response and
**must not be changed during resolve.**
If any language server responds with different `textEdit`, `insertText`,
etc. in `completionItem/resolve` than in `textDocument/completion`, they
should fix that. Bug in this case in `typescript-language-server`:
https://github.com/typescript-language-server/typescript-language-server/pull/303#discussion_r869102064
We don't really need to override these at all. Keeping the existing
Anchors results in correct replacement.
Release Notes:
- Fixed issue where in some cases there would be an extra `}` at the end
of imports when accepting completions.
This pull request should be idempotent, but lays the groundwork for
avoiding to connect to collab in order to interact with AI features
provided by Zed.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
The spec says:
> ⬅️ Initialized Event
> This event indicates that the debug adapter is ready to accept
configuration requests (e.g. setBreakpoints, setExceptionBreakpoints).
>
> A debug adapter is expected to send this event when it is ready to
accept configuration requests (but not before the initialize request has
finished).
Previously in tests, `intercept_debug_sessions` was just spawning off a
background task to send the event after setting up the client, so the
event wasn't actually synchronized with the flow of messages in the way
the spec says it should be. This PR makes it so that the `FakeTransport`
injects the event right after a successful response to the initialize
request, and doesn't send it otherwise.
Release Notes:
- N/A
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:
5537987630/crates/editor/src/editor.rs (L9539-L9545)
which caused eventual autoclose region invalidation:
5537987630/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
c65da547c9/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
This fixes an issue where we were not setting the context server working
directory at all.
Release Notes:
- Context servers will now be spawned in the currently active project
root.
---------
Co-authored-by: Danilo Leal <danilo@zed.dev>
Temporarily fixes#29133
Co-authored-by: Cole <cole@zed.dev>
Release Notes:
- python: Zed now reports a slightly different set of workspace folders
for Python projects to work around quirks in handling of multi-lsp
projects with virtual environment. This behavior will be revisited in a
near future.
Co-authored-by: Cole <cole@zed.dev>
In this PR we've reworked how git status updates are processed. Most
notable change is moving the processing into a background thread (and
splitting it across multiple background workers). We believe it is safe
to do so, as worktree events are not deterministic (fs updates are not
guaranteed to come in any order etc), so I've figured that git store
should not be overly order-reliant anyways.
Note that this PR does not solve perf issues wholesale - other parts of
the system are still slow to process stuff (which I plan to nuke soon).
Related to #34302
Release Notes:
- Improved Zed's performance in projects with large # of repositories
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
we were join(",") and split(",") to serialize the patterns.
This doesn't work when pattern includes a ","
example: *.{ts,tsx} (very common pattern used by agent)
help needed:
how will this work on version mismatch?
Release Notes:
- Fixed search filter patterns on remote projects.
This gets rid of the need to pass context to all cursor functions. In
practice context is always immutable when interacting with cursors.
A nicety of this is in the follow-up PR we will be able to implement
Iterator for all Cursors/filter cursors (hell, we may be able to get rid
of filter cursor altogether, as it is just a custom `filter` impl on
iterator trait).
Release Notes:
- N/A
Closes#31917
Previously, as of #28457 we used a hack, creating an empty transaction
in the history that we then merged formatting changes into in order to
correctly identify concurrent edits to the buffer while formatting was
happening. This caused issues with noop formatting however, as using the
normal API of the buffer history (in an albeit weird way) resulted in
the redo stack being cleared, regardless of whether the formatting
transaction included edits or not, which is the correct behavior in all
other contexts.
This PR fixes the redo issue by codifying the behavior formatting wants,
that being the ability to push an empty transaction to the history with
no other side-effects (i.e. clearing the redo stack) to detect
concurrent edits, with the tradeoff being that it must then manually
remove the transaction later if no changes occurred from the formatting.
The redo stack is still cleared when there are formatting edits, as the
individual format steps use the normal `{start,end}_transaction` methods
which clear the redo stack if the finished transaction isn't empty.
Release Notes:
- Fixed an issue where redo would not work after buffer formatting
(including formatting on save) when the formatting did not result in any
changes
