Follow-up to #30565
This PR fixes the default settings values for the `DiagnosticsSettings`.
The issue here was that due to the `#[derive(Default)]`, `button` would
be false by default, which unintentionally hid the diagnostics button by
default. The `#[serde(default = `default_true`)]` would only apply iff
the diagnostics key was already present in the user's settings. Thus, if
you have
```json
{
"diagnostics": {...}
}
```
in your settings, the button would show (given it was not disabled).
However, if the key was not present, the button was not shown: Due to
the derived default for the entire struct, the value would be false.
This PR fixes this by implementing the default instead and moving the
`#[serde(default)]` up to the level of the struct.
I also did the same for the inline diagnostics settings, which already
had a default impl and thus only needed the serde default on the struct
instead of on all the struct fields.
Lastly, I simplified the title bar settings, since the serde attributes
previously had no effect anyway (deserialization happened in the
`TitlebarSettingsContent`, so these attributes had no effect) and we can
remove the `TitlebarSettingsContent` as well as the attributes if we
implement a proper default implementation instead.
Release Notes:
- Fixed the diagnostics status bar button being hidden by default.
The first panic was caused by an unwrap that assumed a file would always
have a root syntax node.
The second was caused by a double lease panic when clicking enter in the
debug console while there was a completion menu open
Release Notes:
- N/A
* project search button in the status bar
```jsonc
"search": {
"button": false
},
```
* project diagnostics button in the status bar
```jsonc
"diagnostics": {
"button": false
}
```
* project name and host buttons in the title bar
```jsonc
"title_bar": {
"show_project_items": false
}
```
* git branch button in the title bar
```jsonc
"title_bar": {
"show_branch_name": false
}
```
Before:
<img width="1728" alt="before"
src="https://github.com/user-attachments/assets/4b13b431-3ac1-43b3-8ac7-469e5a9ccf7e"
/>
After:
<img width="1728" alt="after"
src="https://github.com/user-attachments/assets/baf2765a-e27b-47a3-8897-89152b7a7c95"
/>
Release Notes:
- Added more settings to hide buttons from Zed UI
Release Notes:
- Fixed a race condition that sometimes prevented a system-installed
`node` binary from being detected.
- Fixed a bug where the `node.path` setting was not respected when
invoking npm.
I noticed some problems where we have hanging debug sessions after
they've been terminated. This should hopefully fix most cases of this,
if not all.
Release Notes:
- N/A
* Adds a `diagnostics_max_severity: null` editor settings that has
previous hardcoded default, `warning`
* Make inline diagnostics to inherit this setting by default (can be
overridden with its own max_severity setting)
* Allows to toggle diagnostics in the editor menu and via new action,
`editor::ToggleDiagnostics`
Closes https://github.com/zed-industries/zed/issues/4686
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#29982
When auto-importing TypeScript functions with generic type arguments
(like `useRef<HTMLDivElement>(null)`), the language server returns
snippets with placeholders (e.g., `useRef(${1:initialValue})$0`). While
useful for new function calls, this behavior breaks existing code when
renaming functions that already have parameters.
For example, completing `useR^<HTMLDivElement>(null)` incorrectly
results in `useRef(initialValue)^<HTMLDivElement>(null)`.
Related upstream issue:
https://github.com/microsoft/TypeScript/issues/51758
Similar workaround fix:
https://github.com/pmizio/typescript-tools.nvim/pull/147
Release Notes:
- Fixed TypeScript auto-import behavior where functions with generic
type arguments (like `useRef<HTMLDivElement>(null)`) would incorrectly
insert snippet placeholders, breaking the syntax.
- Adds a new smoke test for the use of the read_file tool by the agent
in an SSH project
- Fixes the SSH shutdown sequence to use a timer from the app's executor
instead of always using a real timer
- Changes the main executor loop for tests to advance the clock
automatically instead of panicking with `parked with nothing left to
run` when there is a delayed task
Release Notes:
- N/A
Sometimes models return absolute paths even though we ask them not to
(including sometimes returning `/dev/null`). Currently we assume we're
always given a relative path, which leads to a panic in debug builds.
Now we just support being given absolute paths.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <hi@aguz.me>
### Todo
* [x] Allow opening `ssh://username@host:/` from the CLI
* [x] Allow selecting `/` in the `open path` picker
* [x] Allow selecting the home directory in the `open path` picker
Release Notes:
- Changed the initial state of the SSH project picker to show the full
path to your home directory on the remote machine, instead of `~`.
- Added the ability to open `/` as a project folder over SSH
---------
Co-authored-by: Agus Zubiaga <hi@aguz.me>
## Context
This PR improves the accuracy of our inline values for Rust/Python. It
does this by only adding inline value hints to the last valid use of a
variable and checking whether variables are valid within a given scope
or not.
We also added tests for Rust/Python inline values and inline values
refreshing when stepping in a debug session.
### Future tasks
1. Handle functions that have inner functions defined within them.
2. Add inline values to variables that were used in inner scopes but not
defined in them.
3. Move the inline value provider trait and impls to the language trait
(or somewhere else).
4. Use Semantic tokens as the first inline value provider and fall back
to tree sitter
5. add let some variable statement, for loops, and function inline value
hints to Rust.
6. Make writing tests more streamlined.
6.1 We should be able to write a test by only passing in variables,
language, source file, expected result, and stop position to a function.
7. Write a test that has coverage for selecting different stack frames.
co-authored-by: Remco Smits \<djsmits12@gmail.com\>
Release Notes:
- N/A
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Adds a new `agent.model_parameters` setting that allows the user to
specify a custom temperature for a provider AND/OR model:
```json5
"model_parameters": [
// To set parameters for all requests to OpenAI models:
{
"provider": "openai",
"temperature": 0.5
},
// To set parameters for all requests in general:
{
"temperature": 0
},
// To set parameters for a specific provider and model:
{
"provider": "zed.dev",
"model": "claude-3-7-sonnet-latest",
"temperature": 1.0
}
],
```
Release Notes:
- agent: Allow customizing temperature by provider/model
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
- Languages now define their preferred debuggers in `config.toml`.
- `LanguageRegistry` now exposes language config even for languages that
are not yet loaded. This necessitated extension registry changes (we now
deserialize config.toml of all language entries when loading new
extension index), but it should be backwards compatible with the old
format. /cc @maxdeviant
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
There were two bugs that caused user-defined debug scenarios from being
able to run a build task.
1. DebugRequest would be deserialized to `Attach` even when `process_id`
wasn't defined in a user's configuration file. This has been fixed by
adding our own deserializer that defaults to None if there are no fields
present instead of `Attach`, and I added tests to prevent regressions.
2. Debug scenario resolve phase never got the active buffer when
spawning a debug session from the new session modal. This has been
worked around by passing in the worktree_id of a debug scenario in the
scenario picker and the active worktree_id otherwise.
Release Notes:
- N/A
Currently contains the pre-work of making sessions creatable without a
definition, but still need to change the spawn in terminal
to use the running session
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
WIP
- On macOS/Linux, run the command in bash instead of the user's shell
- Try to prevent the agent from running commands that expect interaction
Release Notes:
- Agent Beta: Switched to using `bash` (if available) instead of the
user's shell when calling the terminal tool.
- Agent Beta: Prevented the agent from hanging when trying to run
interactive commands.
---------
Co-authored-by: WeetHet <stas.ale66@gmail.com>
Because we instantiated `ContextServerManager` both in `agent` and
`assistant-context-editor`, and these two entities track the running MCP
servers separately, we were effectively running every MCP server twice.
This PR moves the `ContextServerManager` into the project crate (now
called `ContextServerStore`). The store can be accessed via a project
instance. This ensures that we only instantiate one `ContextServerStore`
per project.
Also, this PR adds a bunch of tests to ensure that the
`ContextServerStore` behaves correctly (Previously there were none).
Closes#28714Closes#29530
Release Notes:
- N/A
Nathan here: I also tacked on a bunch of UI refinement.
Release Notes:
- Introduced the ability to follow the agent around as it reads and
edits files.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
I also moved the breakpoint store to session from local mode, because
both remote/local modes will need the ability to remove active debug
lines.
Release Notes:
- N/A
## Preview
### TODO
- [x] Add scenario picker to new session modal
- [x] Make debugger start action open new session modal instead of task
modal
- [x] Fix `esc` not clearing the cancelling the new session modal while
it's in scenario or attach mode
- [x] Resolve debug scenario's correctly
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/29706
Instead of doing `cargo check` manually, use rust-analyzer's flycheck:
at the cost of more sophisticated check command configuration, we keep
much less code in Zed, and get a proper progress report.
User-facing UI does not change except `diagnostics_fetch_command` and
`env` settings removed from the diagnostics settings.
Release Notes:
- N/A
Release Notes:
- Changed the git branch picker to make remote-tracking branches less
prominent
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Adjusts the way `cargo` and `rust-analyzer` diagnostics are fetched into
Zed.
Nothing is changed for defaults: in this mode, Zed does nothing but
reports file updates, which trigger rust-analyzers'
mechanisms:
* generating internal diagnostics, which it is able to produce on the
fly, without blocking cargo lock.
Unfortunately, there are not that many diagnostics in r-a, and some of
them have false-positives compared to rustc ones
* running `cargo check --workspace --all-targets` on each file save,
taking the cargo lock
For large projects like Zed, this might take a while, reducing the
ability to choose how to work with the project: e.g. it's impossible to
save multiple times without long diagnostics refreshes (may happen
automatically on e.g. focus loss), save the project and run it instantly
without waiting for cargo check to finish, etc.
In addition, it's relatively tricky to reconfigure r-a to run a
different command, with different arguments and maybe different env
vars: that would require a language server restart (and a large project
reindex) and fiddling with multiple JSON fields.
The new mode aims to separate out cargo diagnostics into its own loop so
that all Zed diagnostics features are supported still.
For that, an extra mode was introduced:
```jsonc
"rust": {
// When enabled, Zed runs `cargo check --message-format=json`-based commands and
// collect cargo diagnostics instead of rust-analyzer.
"fetch_cargo_diagnostics": false,
// A command override for fetching the cargo diagnostics.
// First argument is the command, followed by the arguments.
"diagnostics_fetch_command": [
"cargo",
"check",
"--quiet",
"--workspace",
"--message-format=json",
"--all-targets",
"--keep-going"
],
// Extra environment variables to pass to the diagnostics fetch command.
"env": {}
}
```
which calls to cargo, parses its output and mixes in with the existing
diagnostics:
https://github.com/user-attachments/assets/e986f955-b452-4995-8aac-3049683dd22c
Release Notes:
- Added a way to get diagnostics from cargo and rust-analyzer without
mutually locking each other
- Added `ctrl-r` binding to refresh diagnostics in the project
diagnostics editor context
This PR updates the git store to not register a change in a repository's
merge heads until conflicted paths are seen.
We currently use the repository's merge heads only to decide when the
list of conflicted paths should be refreshed. Previously, the logic
looked like this:
- Whenever we see a change in the merge heads, set the list of
conflicted paths by filtering the output of `git status`.
It turns out that when a conflicting merge takes a while, we can see
this sequence of events:
1. We get an event in .git and reload statuses and merge heads.
Previously there were no merge heads, and now we have some, but git
hasn't finished figuring out which paths have conflicts, so we set the
list of conflicted paths to `[]`.
2. Git finishes computing the list of conflicted paths, and we run
another scan that picks these up from `git status`, but then we throw
them away because the merge heads are the same as in (1).
By not updating our stored merge heads until we see some conflicts in
`git status`, we delay this step until (2), and so the conflicted paths
show up in the git panel as intended.
This means that our merge heads state no longer matches what's on disk
(in particular, during a clean merge we'll never update them at all),
but that's okay because we only keep this state for the purpose of
organizing conflicts.
Release Notes:
- Fixed a bug that could cause conflicted paths to not appear in their
own section in the git panel.
Piotr Osiewicz