Closes [#13107](https://github.com/zed-industries/zed/issues/13107)
Enabled pull diagnostics by default, for the language servers that
declare support in the corresponding capabilities.
```
"diagnostics": {
"lsp_pull_diagnostics_debounce_ms": null
}
```
settings can be used to disable the pulling.
Release Notes:
- Added support for the LSP `textDocument/diagnostic` command.
# Brief
This is draft PR that implements the LSP `textDocument/diagnostic`
command. The goal is to receive your feedback and establish further
steps towards fully implementing this command. I tried to re-use
existing method and structures to ensure:
1. The existing functionality works as before
2. There is no interference between the diagnostics sent by a server and
the diagnostics requested by a client.
The current implementation is done via a new LSP command
`GetDocumentDiagnostics` that is sent when a buffer is saved and when a
buffer is edited. There is a new method called `pull_diagnostic` that is
called for such events. It has debounce to ensure we don't spam a server
with commands every time the buffer is edited. Probably, we don't need
the debounce when the buffer is saved.
All in all, the goal is basically to get your feedback and ensure I am
on the right track. Thanks!
## References
1.
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_pullDiagnostics
## In action
You can clone any Ruby repo since the `ruby-lsp` supports the pull
diagnostics only.
Steps to reproduce:
1. Clone this repo https://github.com/vitallium/stimulus-lsp-error-zed
2. Install Ruby (via `asdf` or `mise).
4. Install Ruby gems via `bundle install`
5. Install Ruby LSP with `gem install ruby-lsp`
6. Check out this PR and build Zed
7. Open any file and start editing to see diagnostics in realtime.
https://github.com/user-attachments/assets/0ef6ec41-e4fa-4539-8f2c-6be0d8be4129
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
This is the first step to closing #16120. Part of the problem was that
`surrounding_word` would search the whole line for matches with no
limit.
Co-authored-by: Conrad Irwin \<conrad@zed.dev\>
Co-authored-by: Ben Kunkle \<ben@zed.dev\>
Co-authored-by: Cole Miller \<cole@zed.dev\>
Release Notes:
- N/A
This reverts commit 1e55e88c18.
Closes #ISSUE
Release Notes:
- Python toolchain selector now uses path to the closest pyproject.toml
as a basis for picking a toolchain. All files under the same
pyproject.toml (in filesystem hierarchy) will share a single virtual
environment. It is possible to have multiple Python virtual environments
selected for disjoint parts of the same project.
Parses project's package.json to better detect Jasmine, Jest, Vitest and
Mocha and `test`, `build` scripts presence.
Also tries to detect `pnpm` and `npx` as test runners, falls back to
`npm`.
https://github.com/user-attachments/assets/112d3d8b-8daa-4ba5-8cb5-2f483036bd98
Release Notes:
- Improved TypeScript task detection
* stopped fetching LSP tasks for too long (but still use the hardcoded
value for the time being — the LSP tasks settings part is a simple bool
key and it's not very simple to fit in another value there)
* introduced `prefer_lsp` language task settings value, to control
whether in the gutter/modal/both/none LSP tasks are shown exclusively,
if possible
Release Notes:
- Added a way to prefer LSP tasks over Zed tasks
Closes #ISSUE
Release Notes:
- Added support for importing settings from cursor. Cursor settings can
be imported using the `zed: import cursor settings` command from the
command palette
Closes#8408Closes#10997
This is a reboot of [my original
PR](https://github.com/zed-industries/zed/pull/11697) from last year. I
believe that I've addressed all the comments raised in that original
review, but Zed has changed a lot in the past year, so I'm sure there
will be some new stuff to consider too.
- updates the language matching and lookup to consider not just "does
the suffix/glob match" but also "... and is it the longest such match"
- adds a new `LanguageCustomFileTypes` struct to pass user globs from
settings to the registry
- _minor/unrelated:_ updates a test for the JS extension that wasn't
actually testing what is intended to
- _minor/unrelated:_ removed 2 redundant path extensions from the JS
lang extension
**Languages that may use this**
- Laravel Blade templates use the `blade.php` compound extension
-
[apparently](https://github.com/zed-industries/zed/issues/10765#issuecomment-2091293304)
Angular uses `component.html`
- see also https://github.com/zed-industries/extensions/issues/169
- _hypothetically_ someone could publish a "JS test" extension w/ custom
highlights and/or snippets; many JS tests use `test.js` or `spec.js`
**Verifying these changes**
I added a number of assertions for this new behavior, and I also
confirmed that the (recently patched) [Laravel Blade
extension](https://github.com/bajrangCoder/zed-laravel-blade) opens as
expected for `blade.php` files, whereas on `main` it does not.
cc @maxbrunsfeld (reviewed my original PR last year), @osiewicz and
@MrSubidubi (have recently been in this part of the code)
Release Notes:
- Added support for "compound" file extensions in language extensions,
such `blade.php` and `component.html`. Closes#8408 and #10997.
This is the first step of ["Solution proposal for folding multiline
comments with no
indentation"](https://github.com/zed-industries/zed/discussions/31395):
> 1. Add block_comment in the config.toml for the languages javascript,
typescript, tsx. These are simple languages for this feature, and I am
already familiar with them.
The next step will be:
> 2. Modify the function `crease_for_buffer_row` in `DisplaySnapshot` to
handle multiline comments. `editor::fold` and `editor::fold_all` will
handle multiline comments after this change. To my knowledge,
`editor::unfold`, `editor::unfold_all`, and the **unfold** indicator in
the gutter will already work after folding, but there will be no
**fold** indicator.
Release Notes:
- N/A
Don't hard wrap interactively; instead, soft wrap in `Bounded` mode
(editor width or 72 chars, whichever is smaller), and then hard wrap
before sending the commit message to git.
This also makes the soft wrap mode and width for commit messages
configurable in language settings.
Previously we didn't support soft wrap modes other than `EditorWidth` in
auto-height editors; I tried to add support for this by analogy with
code that was already there, and it seems to work pretty well.
Closes#27508
Release Notes:
- Fixed confusing wrapping behavior in commit message editors.
Follow-up to #29625 and #30902
This PR reintroduces auto-intents for brackets in Python and fixes some
cases where an indentation would be triggered if it should not. For
example, upon typing
```python
a = []
```
and inserting a newline after, the next line would be indented although
it shoud not be.
Bracket auto-indentation was tested prior to #29625 but removed there
and the test updated accordingly. #30902 reintroduced this for all
brackets but `()`. I reintroduced this here, reverted the changes to the
test so that indents also happen after typing `()`. This is frequently
used for tuples and multiline statements in Python.
Release Notes:
- Improved auto-indentation when using round brackets in Python.
This change improves `eval_extract_handle_command_output` results for
all models:
Model | Pass rate before | Pass rate after
----------------------------|------------------|----------------
claude-3.7-sonnet | 0.96 | 0.98
gemini-2.5-pro | 0.35 | 0.86
gpt-4.1 | 0.81 | 1.00
Part of this improvement comes from more robust evaluation, which now
accepts multiple possible outcomes. Another part is from the prompt
adaptation: addressing common Gemini failure modes, adding a few-shot
example, and, in the final commit, auto-rewriting instructions for
clarity and conciseness.
This change still needs validation from larger end-to-end evals.
Release Notes:
- N/A
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
Follow up for https://github.com/zed-industries/zed/pull/30768
This PR makes JSDoc auto comment on new line lot better by:
- Inserting delimiters regardless of whether previous delimiters have
trailing spaces or not
- When on start tag, auto-indenting both prefix and end tag upon new
line
This makes it correct as per convention out of the box. No need to
manually adjust spaces on every new line.
https://github.com/user-attachments/assets/81b8e05a-fe8a-4459-9e90-c8a3d70a51a2
Release Notes:
- Improved JSDoc auto-commenting on newline which now correctly indents
as per convention.
We attempt to resolve the language name in this order
1. Based on debug adapter if they're for a singular language e.g. Delve
2. File extension if it exists
3. If a language name exists within a debug scenario's label
In the future I want to use locators to also determine the language as
well and refresh scenario list when a new scenario has been saved
Release Notes:
- N/A
Closes#27582
Now, when accepting function completion, it doesn't expand with
parentheses and arguments in the following cases:
1. If it's in a string (like `type Foo = MyClass["sayHello"]` instead of
`type Foo = MyClass["sayHello(name)"]`)
2. If it's in a call expression (like `useRef<HTMLDivElement>(null)`
over `useRef(initialValue)<HTMLDivElement>(null)`)
This is a follow-up to https://github.com/zed-industries/zed/pull/30312,
more like cleaner version of it.
Release Notes:
- Fixed an issue where accepting a method as an object string in
JavaScript would incorrectly expand. E.g. `MyClass["sayHello(name)"]`
instead of `MyClass["sayHello"]`.
Closes#26157
This fixes multiple cases where Python indentation breaks:
- [x] Adding a new line after `if`, `try`, etc. correctly indents in
that scope
- [x] Multi-cursor tabs correctly preserve relative indents
- [x] Adding a new line after `else`, `finally`, etc. correctly outdents
them
- [x] Existing Tests
Future Todo: I need to add new tests for all the above cases.
Before/After:
1. Multi-cursor tabs correctly preserve relative indents
https://github.com/user-attachments/assets/08a46ddf-5371-4e26-ae7d-f8aa0b31c4a2
2. Adding a new line after `if`, `try`, etc. correctly indents in that
scope
https://github.com/user-attachments/assets/9affae97-1a50-43c9-9e9f-c1ea3a747813
Release Notes:
- Fixes indentation-related issues involving tab, newline, etc for
Python.
## 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>
- 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>
Closes#28699
Fixes two cases in the `editor::SelectLargerSyntaxNode` action:
1. When cursor is at the end of a word, it now selects that word first
instead of selecting the whole line.
2. When cursor is at the end of a line, it now selects that line first
instead of selecting the whole code block.
Before and After:
https://github.com/user-attachments/assets/233b891e-15f1-4f10-a51f-75693323c2bd
Release Notes:
- Fixed `editor::SelectLargerSyntaxNode` to properly select nodes when
the cursor is positioned at the end of words or lines.
Closes #ISSUE
Release Notes:
- Agent Beta: Renamed the top-level `assistant` settings key to `agent`.
A migration for existing settings files is included.
- Agent Beta: Moved the `assistant::ToggleFocus`,
`assistant::ToggleModelSelector`, and `assistant::OpenRulesLibrary`
actions to the `agent` namespace. Existing keymaps that mention these
actions by their old names will continue to work.
---------
Co-authored-by: Max <max@zed.dev>
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>
Refs #29733
This pull request introduces a new field to the `StreamingEditFileTool`
that lets the model create or overwrite a file in a streaming way. When
one of the `assistant.stream_edits` setting / `agent-stream-edits`
feature flag is enabled, we are going to disable the `CreateFileTool` so
that the agent model can only use `StreamingEditFileTool` for file
creation.
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Oleksiy Syvokon <oleksiy.syvokon@gmail.com>
This pull request introduces a new tool for streaming edits. The
short-term goal is for this tool to replace the existing `EditFileTool`,
but we want to get this out the door as soon as possible so that we can
start testing it.
`StreamingEditFileTool` is mutually exclusive with `EditFileTool`. It
will be enabled by default for anyone who has the `agent-stream-edits`
feature flag, as well as people that set `assistant.stream_edits` to
`true` in their settings.
### Implementation
Streaming is achieved by requesting a completion while the `edit_file`
tool gets called. We invoke the model by taking the existing
conversation with the agent and appending a prompt specifically tailored
for editing. In that prompt, we ask the model to produce a stream of
`<old_text>`/`<new_text>` tags. As the model streams text in, we
incrementally parse it and start editing as soon as we can.
### Evals
Note that, as part of this pull request, I also defined some new evals
that I used to drive the behavior of the recursive LLM call. To run
them, use this command:
```bash
cargo test --package=assistant_tools --features eval -- eval_extract_handle_command_output
```
Or comment out the `#[cfg_attr(not(feature = "eval"), ignore)]` macro.
I recommend running them one at a time, because right now we don't
really have a way of orchestrating of all these evals. I think we should
invest into that effort once the new agent panel goes live.
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Co-authored-by: Oleksiy Syvokon <oleksiy.syvokon@gmail.com>
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
- Stop merging same row diagnostics
- (for Rust) show code fragments surrounded by `'s in monospace
Co-authored-by: Serge Radinovich <sergeradinovich@gmail.com>
Closes#29362
Release Notes:
- diagnostics: Diagnostics are no longer merged when they're on the same
line
- rust: Diagnostics now show code snippets in monospace font:
<img width="551" alt="Screenshot 2025-04-29 at 16 13 45"
src="https://github.com/user-attachments/assets/d289be31-717d-404f-a76a-a0cda3e96fbe"
/>
Co-authored-by: Serge Radinovich <sergeradinovich@gmail.com>
Closes#28135Closes#4388Closes#28136
Release Notes:
- diagnostics: Show the diagnostic code if available
---------
Co-authored-by: Neo Nie <nihgwu@live.com>
Co-authored-by: Zed AI <ai+claude-3.7@zed.dev>
This PR uses Tree Sitter to show inline values while a user is in a
debug session.
We went with Tree Sitter over the LSP Inline Values request because the
LSP request isn't widely supported. Tree Sitter is easy for
languages/extensions to add support to. Tree Sitter can compute the
inline values locally, so there's no need to add extra RPC messages for
Collab. Tree Sitter also gives Zed more control over how we want to show
variables.
There's still more work to be done after this PR, namely differentiating
between global/local scoped variables, but it's a great starting point
to start iteratively improving it.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <peterosiewicz@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Cole Miller <m@cole-miller.net>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Kirill <kirill@zed.dev>
Things this doesn't currently handle:
- [x] ~testing~
- ~we really need an snapshot test that takes a vscode settings file
with all options that we support, and verifies the zed settings file you
get from importing it, both from an empty starting file or one with lots
of conflicts. that way we can open said vscode settings file in vscode
to ensure that those options all still exist in the future.~
- Discussed this, we don't think this will meaningfully protect us from
future failures, and we will just do this as a manual validation step
before merging this PR. Any imports that have meaningfully complex
translation steps should still be tested.
- [x] confirmation (right now it just clobbers your settings file
silently)
- it'd be really cool if we could show a diff multibuffer of your
current settings with the result of the vscode import and let you pick
"hunks" to keep, but that's probably too much effort for this feature,
especially given that we expect most of the people using it to have an
empty/barebones zed config when they run the import.
- [x] ~UI in the "welcome" page~
- we're planning on redoing our welcome/walkthrough experience anyways,
but in the meantime it'd be nice to conditionally show a button there if
we see a user level vscode config
- we'll add it to the UI when we land the new walkthrough experience,
for now it'll be accessible through the action
- [ ] project-specific settings
- handling translation of `.vscode/settings.json` or `.code-workspace`
settings to `.zed/settings.json` will come in a future PR, along with UI
to prompt the user for those actions when opening a project with local
vscode settings for the first time
- [ ] extension settings
- we probably want to do a best-effort pass of popular extensions like
vim and git lens
- it's also possible to look for installed/enabled extensions with `code
--list-extensions`, but we'd have to maintain some sort of mapping of
those to our settings and/or extensions
- [ ] LSP settings
- these are tricky without access to the json schemas for various
language server extensions. we could probably manage to do translations
for a couple popular languages and avoid solving it in the general case.
- [ ] platform specific settings (`[macos].blah`)
- this is blocked on #16392 which I'm hoping to address soon
- [ ] language specific settings (`[rust].foo`)
- totally doable, just haven't gotten to it yet
~We may want to put this behind some kind of flag and/or not land it
until some of the above issues are addressed, given that we expect
people to only run this importer once there's an incentive to get it
right the first time. Maybe we land it alongside a keymap importer so
you don't have to go through separate imports for those?~
We are gonna land this as-is, all these unchecked items at the bottom
will be addressed in followup PRs, so maybe don't run the importer for
now if you have a large and complex VsCode settings file you'd like to
import.
Release Notes:
- Added a VSCode settings importer, available via a
`zed::ImportVsCodeSettings` action
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Closes#29176
This PR fix an issue where uncommenting a code block in Markdown would
add Markdown comments instead of removing the language-specific
comments.
Why?
`language_scope_at` for comments in a code block in Markdown would
result in the language being detected as Markdown. This happens because
the smallest range, such as `//` or `#` on the Markdown layer, is
preferred over `// whole comment line` for any other language. This
results in language detection as Markdown for that point.
To fix this, we also use a depth factor and try to prefer the layer with
greater depth over one with lesser depth. In this case, the code block's
language depth would be preferred over Markdown. The smallest range is
now used as a tiebreaker.
Added test for this case.
Release Notes:
- Fixed issue where uncommenting a code block in Markdown would add
Markdown comments instead of removing the language comments.
Release Notes:
- "Block" diagnostics (that show up in the diagnostics view, or when
using `f8`/`shift-f8`) are rendered more clearly
- `f8`/`shift-f8` now always go to the "next" or "prev" diagnostic,
regardless of the state of the editor
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Julia Ryan <juliaryan3.14@gmail.com>
