LSP 3.18 allows servers to send [`MarkupContent` diagnostic
messages](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#diagnostic),
guarded by the client capability
`textDocument.diagnostic.markupMessageSupport`.
- Advertise `markup_message_support` only while pull diagnostics are
enabled because `textDocument.diagnostic` is the pull-model capability.
LSP 3.18 currently has no equivalent capability for push diagnostics:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#diagnosticClientCapabilitieshttps://github.com/microsoft/language-server-protocol/issues/2246
- Handle `string | MarkupContent` messages in both push and pull
diagnostic paths: markdown-kind messages populate the existing
`Diagnostic::markdown` field (rendered in hover popovers and the
diagnostics panel), plaintext-kind markup remains plain text, and plain
string messages keep going through the adapter's
`diagnostic_message_to_markdown`.
- Preserve server-provided markup for code actions sent back to the
originating server, avoid forwarding markup diagnostics to other
servers, and render diagnostic metadata without altering the
server-provided markdown.
- Carry the markup kind over RPC via a new optional
`LspDiagnostic.markup_message_kind` proto field so remote/collab
projects round-trip `MarkupContent` messages.
Depends on the lsp-types change that turns `Diagnostic.message` into a
`DiagnosticMessage` enum (`string | MarkupContent`):
https://github.com/zed-industries/lsp-types/pull/15
Once merged, Cargo.toml can point to the upstream commit.
Note that Zed already rendered some plain-string diagnostics as Markdown
through language-specific adapter hooks, including `rust-analyzer`. This
adds protocol-level support for diagnostics explicitly sent as LSP 3.18
`MarkupContent`, while preserving the existing adapter fallbacks.
As a result, this does not introduce a new diagnostics rendering
pipeline.
Server-provided Markdown is routed through the existing
`Diagnostic::markdown` path, with small fixes to handle Markdown-only
updates and block content correctly.
## Showcase
Example from [JETLS.jl](github.com/aviatesk/JETLS.jl) (a Julia language
server):
> Before
<img width="924" height="160" alt="Screenshot 2026-07-15 at 16 05 40"
src="https://github.com/user-attachments/assets/b19fe9e3-50e3-44e4-9b4d-ac8bd438d3d6"
/>
> After
<img width="924" height="160" alt="Screenshot 2026-07-15 at 14 13 05"
src="https://github.com/user-attachments/assets/359c3382-118d-4fa6-aa91-6bd3661d3d28"
/>
---
Release Notes:
- Added support for rendering LSP 3.18 Markdown diagnostic messages from
language servers.
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Allows configuring the Bash LSP.
Tested with the following config:
```json
"bash-language-server": {
"binary": {
"path": "bash-language-server",
"arguments": ["start"]
},
"settings": {
"bashIde": {
"shfmt": {
"binaryNextLine": true,
"caseIndent": true,
"spaceRedirects": true,
"simplifyCode": true
}
}
}
}
```
Config options [defined
here](https://github.com/bash-lsp/bash-language-server/blob/main/server/src/config.ts),
all prefixed with `bashIde`.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Added support for configuring the Bash LSP adapter.
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Refactors our query loading to instead have an enum of supported queries
and load the query files themselves in parallel, where possible.
We will use this to warn extension authors when unsupported queries are
present, as we no longer want to ship those as part of the extension.
It also now enforces one file per supported query - only one extension
currently utilizes this feature and was undocumented previously, so I
decided in favor of removing it here, since this will help with
enforcing extensions to just ship query files we actually support in the
future. The extension has also been migrated so that it does not break
with this effort
Side-effect of this change is that we now load both embedded and
external languages up to at least 10%/5% faster, since the files are now
read in parallel as opposed to sequentially one by one.
Release Notes:
- N/A
# Objective
Closes#62624
Recently, Pyright and BasedPyright changed how they retrieve analysis
settings through `workspace/configuration` in microsoft/pyright#11480
and DetachHead/basedpyright#1847, respectively. Older versions requested
the dotted `python.analysis` and `basedpyright.analysis` sections
directly. Recent versions instead request the parent `python` or
`basedpyright` section and read its nested `analysis` object. Because
Zed stores many existing configurations under the dotted top-level keys,
those settings are not included in its responses to the new
parent-section requests and are therefore silently ignored.
Zed's documentation and many users' settings still use configurations
like this:
https://github.com/zed-industries/zed/blob/4155155572601034cec5e5cfa9805bf88957553c/docs/src/languages/python.md?plain=1#L131-L148
all the configrations in `basedpyright.analysis` won't work now.
## Solution
To maintain compatibility with both old and new servers, we need to
support both configuration formats. This PR introduces
`normalize_pyright_analysis_configuration`, which copies the analysis
settings into both the dotted and nested formats. This ensures that the
settings are available regardless of which format the language server
requests.
The documentation, however, has been updated to use the nested
structure.
## Testing
New unit tests have been added, and the changes have also been built and
tested locally.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed some Pyright and BasedPyright settings not being applied
properly.
# Objective
Opening a file laods it twice. `decode_file_text` builds the whole file
as a `String`, and that `String` stays alive alongside the finished rope
while `text::Buffer::new` copies it in. The `Vec` behind it grows by
doubling, so it also commits up to nearly the file's size again in
capacity it never uses.
Partially addresses #27283.
## Solution
Add `decode_file_text_to_rope`, which streams the file in 1 MB blocks
straight into a `Rope`, validating UTF-8 and normalizing line endings as
it goes. The file is never fully held as a `String`.
`LoadedFile::text` becomes a `Rope` carrying the `LineEnding` detected
before normalizing, so `buffer_store` calls `Buffer::new_normalized`.
## Testing
On a 729 MB SQL dump, peak memory fell 25% and CPU fell around 28%.
tested on 5950x, win11.
Release Notes:
- Improved memory use when opening large files, reducing peak memory
during load by roughly the size of the file itself.
# Objective
Fixes#62529.
Prevent Python toolchain discovery from executing Apple's
`/usr/bin/python3` Command Line Tools shim when no active developer
Python exists. Executing that unresolved shim causes macOS to repeatedly
prompt users to install the Command Line Tools, even when Python is
managed through Nix, uv, or pyenv.
## Solution
Update Python Environment Tools (PET) to `bb8e046`, which includes
microsoft/python-environment-tools#506. That upstream change resolves
active Xcode and Command Line Tools Python executables from filesystem
state and skips unresolved macOS system Python shims before generic
process probing.
Adapt Zed to the updated PET API by:
- displaying the newly supported Hatch environment kind
- passing no refresh identifier when running in-process environment
discovery
## Testing
- `cargo check -p languages --locked`
- PET unit tests covering unresolved macOS system Python shims
- The Zed compilation check was run on Linux; the original dialog
reproduction was not manually tested on macOS.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed Python toolchain discovery prompting installation of Apple
Command Line Tools when using a separately managed Python installation.
# Objective
Prevent auto-indent from using stale syntax when text changes during a
background parse.
## Solution
Keep auto-indent pending and parsing active until the current parse
completes.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Editor: Fixed auto-indent occasionally using stale syntax after rapid
edits.
## Why
JavaScript, TypeScript, and TSX class declarations were captured as
`type.class`, but the same class names in `new` expressions were
captured as the generic `type`. Themes that define a distinct style for
`type.class` therefore rendered declarations and instantiations
inconsistently.
## What
Update the three highlight queries so constructor identifiers in `new`
expressions use `type.class`. Themes without a dedicated `type.class`
style continue to fall back to their existing `type` style.
Add a regression test that loads the real JavaScript, TypeScript, and
TSX grammars with distinct colors for `type` and `type.class`, then
verifies that both the declaration and instantiation receive the
class-specific highlight.
## Testing
- `cargo test -p languages test_class_instantiation_highlighting`
- `cargo test -p languages`
- `cargo fmt --all -- --check`
- `./script/clippy -p languages`
## References
Closes#55943
Release Notes:
- Fixed inconsistent class instantiation highlighting in JavaScript,
TypeScript, and TSX.
This adds a dedicated `AvailableLanguages` struct in preparation for a
more cabable language matching based on a given language config. No
functional changes, just shuffling some code around for this round.
Also made the LanguageMatcher non-cloneable in favor of wrapping it in
an Arc, since cloning is rather expensive for this and having a
reference is sufficient in all cases right now.
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
In lsp_store, user's lsp initialization_options are merged into the
adapter's
defaults using `merge_json_value_into`; this merges by concatenating
arrays,
which can produce duplicate entries.
Adds merge_json_value_into_replacing_arrays, a variant that replaces
arrays instead of merging; uses it for LSP initialization options.
`merge_json_value_into` is kept since some callers intentionally
use array concatenation (extending rust-analyzer's
experimental.commands.commands list).
Closes#54892
Release Notes:
- Fixed duplicated or extra array values in LSP `initialization_options`
when user settings override LSP defaults with an array
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Correct memory values: 8 GiB limit (8192) and tsserver max memory set to
16384 for TypeScript and JavaScript examples.
# Objective
- Standardized memory values.
## Testing
- This commit not be tested.
## Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [X] Unsafe blocks (if any) have justifying comments
- [X] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [X] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Closes#60761
Follow-up to #60970, which fixed this for `typescript-language-server`.
`vtsls` had the same problem, we only checked that the workspace tsdk
directory exists, but TypeScript 7 ships it without `tsserver.js`,
causing vtsls to error on startup.
Now we do the same `tsserver.js` check, so vtsls silently falls back to
its bundled TypeScript (see #60951).
Release Notes:
- Fixed vtsls showing a "doesn't point to a valid tsserver install"
error on startup in projects using TypeScript 7. For full TypeScript 7
support, install the `tsgo` extension to use TypeScript's native
language server.
# Objective
Closes#55936
Helps #57288
There is a strange behavior for Python users when using basedpyright or
pyright as the language server. As reported in #55936, when no settings
are configured in `lsp.basedpyright.settings`, the language server
correctly receives toolchain information discovered by Zed:
```json
{
"venvPath": ".",
"venv": ".venv",
"python": {
"pythonPath": "/home/xin/works/test/test_python/.venv/bin/python",
"defaultInterpreterPath": "/home/xin/works/test/test_python/.venv/bin/python"
},
"basedpyright.analysis": {
"typeCheckingMode": "standard"
},
"basedpyright.disableOrganizeImports": true
}
```
However, when the user configures any other settings in
`lsp.basedpyright.settings`, the toolchain information is silently lost.
For example, with the following `settings.json`:
```jsonc
{
"lsp": {
"basedpyright": {
"settings": {
"analysis": {
"diagnosticMode": "workspace",
"typeCheckingMode": "standard",
"inlayHints.callArgumentNames": true,
"inlayHints.variableTypes": true,
},
},
}
}
}
```
The final configuration sent to the language server becomes:
```json
{
"analysis": {
"diagnosticMode": "workspace",
"typeCheckingMode": "standard",
"inlayHints.callArgumentNames": true,
"inlayHints.variableTypes": true
}
}
```
No toolchain information is passed, so the language server ignores the
user's selected Python environment and falls back to whatever virtual
environment it discovers on its own. To make toolchain selection work,
users currently have to manually configure virtual environment settings
themselves (as noted in
https://github.com/zed-industries/zed/issues/57288#issuecomment-4750935341).
This issue was introduced in #48262, which aimed to make the virtual
environment used by basedpyright/pyright configurable. The core logic is
the `should_insert_toolchain` closure, originally designed to check
whether Zed should inject the detected toolchain into the language
server configuration. The intent was: if the user has already configured
a virtual environment in the language server settings, skip the
injection.
https://github.com/zed-industries/zed/blob/d4e43845fa1086512dedafdd2c852d167d005bb0/crates/languages/src/python.rs#L2115-L2128
However, the original logic was inverted — it injected the toolchain
when the user had no settings at all or when they had configured virtual
environment keys. This meant that when the user had LSP settings but no
virtual environment configuration, toolchain injection was skipped, as
reported in #55936.
## Solution
Change the logic defined in `should_insert_toolchain` closure, instead
of insert toolchain when detected virtual environment settings, now we
insert toolchain when no virtual environment settings is detected.
## Testing
Tested locally. The logic change is simple, should be easy for review.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed toolchain selection being ignored when Pyright or Basedpyright
settings are configured without specifying a Python interpreter path
This is necessary to remove some `util` dependencies from crates, as
well as better sharing for our projects. This also includes the WIP
AbsPath abstraction as well as some bug fixes from internal tooling.
Release Notes:
- N/A or Added/Fixed/Improved ...
Closes https://github.com/zed-industries/zed/issues/60618
TypeScript 7 no longer ships `tsserver.js`, which
`typescript-language-server` depends on.
This PR does two things:
1. Pins the `typescript` package Zed auto-installs for
`typescript-language-server` to `^6`. For projects without their own
TypeScript in `node_modules` (which rely on the copy Zed installs), an
existing 7.x install gets downgraded to the latest 6.x, making the
server usable again.
2. Only hands the workspace's TypeScript to the server as a tsdk when it
actually contains `tsserver.js`, falling back to Zed's installed 6.x
otherwise. So if you upgraded your project to TypeScript 7, the language
server won't break. It keeps working against the 6.x TypeScript Zed
ships.
Note that vtsls, the default TypeScript language server, is unaffected
by the TypeScript 7 release. It bundles its own compatible TypeScript.
See #60951 for details. This PR only affects users who have manually
configured `typescript-language-server` as their language server.
Release Notes:
- Fixed `typescript-language-server` breaking after the TypeScript 7
release. For projects that have upgraded to TypeScript 7, install the
`tsgo` extension to use TypeScript's native language server.
Context:
While looking at #60618, I found out the TypeScript 7 upgrade only
breaks the `typescript-language-server` adapter, not the default vtsls
adapter.
After digging in, it turns out the initial vtsls implementation in
#12606 followed the same two-package installation pattern as the
`typescript-language-server` adapter: it installed both
`@vtsls/language-server` and the latest `typescript`. However, vtsls
already bundles a compatible TypeScript version via
`@vtsls/language-service` and uses it whenever a workspace SDK is
unavailable.
I also cross-checked an intermediate vtsls upgrade issue, #18349, where
we used the installed TypeScript version to decide whether both packages
needed updating, so a new vtsls release could go uninstalled when
TypeScript hadn't changed. #20197 fixed that by checking both packages
independently, but kept the unnecessary standalone TypeScript
installation.
Changes:
This PR removes that redundant installation and version tracking from
the vtsls adapter. Zed now tracks only `@vtsls/language-server` and
relies on its declared TypeScript dependency. Workspace TypeScript and
Yarn SDK detection remain unchanged, so vtsls still uses a workspace SDK
when one is available and otherwise falls back to its bundled version.
As for the consequence of this change:
1. New users are not affected since npm installs vtsls's own pinned
TypeScript dependency anyway.
2. For existing users, the previously installed standalone `typescript`
was never resolvable by vtsls (its pinned version gets installed nested
when the versions conflict), so leaving it there is harmless.
To verify the standalone copy was really unused, I nuked the vtsls dir
and ran main (without this fix), which installed both the top-level
`typescript@7.0.2` and vtsls's own pinned `typescript@5.9.3` nested
under `@vtsls/language-service`. Node's module resolution shows vtsls
can only ever see the nested copy as well as the LSP logs from the
running server shows, all lib definition locations point at the nested
copy:
```
"uri": "file:///.../vtsls/node_modules/@vtsls/language-service/node_modules/typescript/lib/lib.es5.d.ts"
```
I also tested this branch with a fresh install TypeScript files work the
same as before.
Release Notes:
- N/A
# Objective
Fixes#60261
Nothing under a `case` gets indented in C or C++, and the next `case`
doesn't come back out. It stays flat until you hit `editor: format`.
## Solution
The indent queries had no rule for case labels. Added the same pair
`cpp/indents.scm` uses for `access_specifier`: open an indent range at
the label, close it at the switch's `}`, outdent on the next label.
The part that got me: `@start` uses the *end* of the node you capture.
Fine for `access_specifier`, which is just `public:`. But a
`case_statement` swallows the statements under it, so capturing the node
starts the range after the last one. Capture the `:` instead. `default:`
is a `case_statement` too, so it comes along free.
Only affects what happens after a label, so existing `case` alignment
doesn't move.
## Testing
`test_c_autoindent_switch_case` and `test_cpp_autoindent_switch_case`
cover a plain case, fall-through labels and `default`. Both fail on
main. The `access_specifier` tests still pass.
Not mine, but worth knowing: `typescript::tests::test_outline` and
`test_generator_function_outline` are flaky on main, failing about half
my full `cargo test -p languages --lib` runs with or without this
change.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed statements under a `case` label not being indented in C and C++
([#60261](https://github.com/zed-industries/zed/issues/60261)).
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
This fixes Go outline extraction for methods whose receiver has no name,
such as `func (v2) Method()`. These methods are now included in outline
symbols, which also feed breadcrumbs and sticky
scroll.
Tested with:
- `cargo test -p languages`
- `cargo test -p grammars`
- `./script/clippy -p languages`
- `cargo fmt --check --package languages`
Before:
[before_cut.webm](https://github.com/user-attachments/assets/91eb5cb0-703a-4496-b0dd-5369c4c219fc)
After:
[after_cut.webm](https://github.com/user-attachments/assets/76d13d88-3671-4118-99fc-c073a6e64727)
Release Notes:
- Fixed Go methods with unnamed receivers not appearing in breadcrumbs
and sticky scroll.
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#57030
When `fullFunctionSignatures` is enabled in `rust-analyzer`, some
completion items returned by the language server have an unexpected
`filterText`. For example:
```jsonc
{
"label": "sync_all(…)",
"labelDetails": {
"detail": "(alias fsync)",
"description": "pub fn sync_all(&self) -> io::Result<()>"
},
"kind": 2,
"sortText": "7ffffffa",
"filterText": "sync_allfsync",
...
}
```
For such completion items, the rust-analyzer adapter falls back to an
outer range passed into the `mk_label` closure to determine the display
range:
https://github.com/zed-industries/zed/blob/22852a6431ca8a5e0fe07a4769e9fe521d2b1b0a/crates/languages/src/rust.rs#L362-L371
For functions or methods, this fallback range is calculated here:
https://github.com/zed-industries/zed/blob/22852a6431ca8a5e0fe07a4769e9fe521d2b1b0a/crates/languages/src/rust.rs#L424-L435
In this example, the `function_signature` is `"pub fn sync_all(&self) ->
io::Result<()>"`, and the regex matches up to `fn sync_all(&self) ->
io::Result<(`. Currently, the range passed to the `mk_label` closure
mistakenly covers `"ub fn sync_all(&self) -> io::Result<"` (causing the
first character 'p' to be truncated, as reported in #57030), whereas we
only want `"sync_all"` itself
This PR introduces two main changes to fix this behavior:
- Adjust the range start: Skip the leading `fn` keyword so that the
range starts exactly at the function or method name.
- Update the regex pattern: The current pattern matches up to the last
`(`, which causes incorrect slicing if the return type contains
parentheses (e.g., `Result<()>`). This is changed to match up to the
first `(`.
Release Notes:
- Fixed some rust completions has `ub fn ` as prefix when
`fullFunctionSignatures` is enabled
# Objective
Consider a simple Python file with the following content, where both a
method and a function are defined:
```python
class TestCase:
def a_test_method(self): # a method
print("This is a method test")
def a_test_function(): # a function
print("This is a function test")
```
Below this, if we type `a_test_func` and trigger language server
completion, we would expect to see `a_test_function` in the completion
list. Similarly, if we have:
```python
test = TestCase()
test.a_testˇ
```
and trigger language server completion, we should see `a_test_method` in
the completion list.
In both cases, we expect the items in the completion list to have the
same color highlighting as they do in the editor buffer, but currently,
they do not. This is because Zed uses the wrong queries to retrieve the
highlight. Taking the `ty` LSP adapter as an example:
https://github.com/zed-industries/zed/blob/ef7fc3c28828ff9edbe35849567634c13ce2ee3b/crates/languages/src/python.rs#L323-L332
the key `"function.method"` and `"function"` are used to look up the
method and function highlight IDs, but these keys do not exist in
`crates/grammars/src/python/highlights.scm`, which defines the syntax
highlighting. The correct keys here should be `"function.method.call"`
and `"function.call"`.
## Solution
- As stated above, change the keys from `"function.method"` and
`"function"` to `"function.method.call"` and `"function.call"`,
respectively.
- Additionally, since we have several built-in language servers for
Python, a minor refactoring has been done to reduce duplicate code and
simplify future changes.
## Testing
- I have tested this change locally; the before and after comparison is
provided below.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
<details>
<summary>Click to view showcase</summary>
| Before | After |
| :---: | :---: |
| <img width="767" height="308" alt="function_before"
src="https://github.com/user-attachments/assets/943852d6-f54e-411d-916f-add7aac57956"
/> | <img width="767" height="308" alt="function_after"
src="https://github.com/user-attachments/assets/3a817229-ce32-4d13-88b8-9e9151869338"
/> |
| <img width="767" height="308" alt="method_before"
src="https://github.com/user-attachments/assets/cbc0f4f4-be6e-44d3-9798-df29df5731a3"
/> | <img width="767" height="308" alt="method_after"
src="https://github.com/user-attachments/assets/6e8f7e84-c5c6-4b37-a2c5-10820f12a09d"
/> |
</details>
---
Release Notes:
- Improved Python completion item highlighting for methods and
functions.
The `go-subtest` task template wrapped the `-run` arg in single quotes
for shell safety. This works for Run Test (terminal strips quotes), but
Debug Test sends the arg through Delve’s DAP protocol with no shell
involved, so the literal quote characters ended up in the regex and
prevented any match.
All other Go task templates (`go-test`, `go-testify-suite`,
`go-table-test-case`) use the backslash-escaped format which `GoLocator`
already knows how to handle. Align the `go-subtest` template to the same
format.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#53230.
Release Notes:
- Fixed Debug Test for Go subtests
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This removes gpui's dependency on the `util` crate, which depends on
async process. It now depends on `gpui_util` only, and uses
`std::process::Command` for the two cases where it was previously using
an async `Command`. This lifts the requirement of non-Zed consumers of
gpui to depend on our forked async-process (see #59156).
Release Notes:
- N/A
Both cloning and dropping of these has quite a bit of overhead (despite
them being snapshots), so avoid where possible, especially in display
map syncing
Release Notes:
- N/A or Added/Fixed/Improved ...
Closes#46881
Depends on #57276.
Implements `GoRunnableResolver` to post-process table test matches. The
resolver picks the correct string field by comparing against the field
used in `t.Run(tc.<field>, ...)`.
Release Notes:
- Fixed Go table tests not showing run buttons in files with many test
cases.
Resolves https://github.com/zed-industries/zed/issues/58086
This diff fixes `package.json` runnables using npm for projects that
declare their package manager through
`devEngines.packageManager`. The `package.json` parser only looked at
the top-level `packageManager` field, so projects using the newer
`devEngines` shape fell back to `npm` even when they specified `pnpm`,
`yarn`, or `bun`.
With this change, package manager detection also reads
`devEngines.packageManager` in both object and array forms. The
top-level `packageManager` field still takes precedence when both are
present, and the shared parser means the fix applies to `package.json`
gutter runnables as well as TypeScript package-script tasks.
Release Notes:
- Fixed `package.json` runnables ignoring package managers declared via
`devEngines.packageManager`.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Stops the `conda activate base` fallback in
`PythonToolchainProvider::activation_script` for two cases:
1. A Conda toolchain whose `environment.name` is `None`.
2. A Conda toolchain whose name is `Some(...)` but `shell.try_quote`
rejects it.
Previously both cases pushed `conda activate base` into the activation
script. With miniforge installed and no env explicitly selected, every
terminal silently activated `(base)`. The user didn't pick `base`;
injecting it is contamination.
Both branches now log a warning and emit no activation line. Users who
want `(base)` can select it as the toolchain explicitly.
Two unit tests cover the new behavior:
`test_conda_activation_skips_when_name_missing` (name=None) and
`test_conda_activation_skips_unquotable_name` (name=Some but unquotable,
exercised with an embedded NUL byte that `shlex::try_quote` rejects).
The existing `test_conda_activation_script_injection` still verifies
that quotable names get activated.
Release Notes:
- Fixed Zed silently injecting `conda activate base` into terminals when
a Conda manager (miniforge/miniconda) was installed but no specific
environment was selected.
rust-analyzer does not really attempt to be backwards compatible, so
when users opt-into the component a toolchain override, we should prefer
that over any other rust-analyzer (especially our own) for better
toolchain compatibility in case people have a more out of date install.
This mirrors the VSCode extension behavior
Release Notes:
- When a worktree contains a Rust toolchain file with a rust analyzer
component specified, Zed will now spawn the given toolchain's
rust-analyzer for toolchain compatability
Zed-managed npm installers were resolving a concrete latest version with
`npm info` and then installing `package@version`. That is brittle when
users
configure npm release-age filtering via `before` or `min-release-age`:
npm's
installer applies those rules during resolution, but our pinned install
target
could disagree with it, and therefore fail to install.
This changes managed npm installs to install `package@latest` and let
npm apply
its own resolver and user config. The local latest-version lookup
remains as a
best-effort cache freshness check, not as the exact install target.
Exact extension API installs remain unchanged because extensions
explicitly
request a package and version. If we want to revisit that we can.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#53611
Release Notes:
- Fixed npm-backed tool installs to better respect npm release-age
filters.
The function is unsound due to the classic fact that one can leak tasks,
sidestepping the blocking drop behavior resulting in a use after free.
Release Notes:
- N/A or Added/Fixed/Improved ...
…/` URI
The ESLint adapter was sending `workspaceFolder.uri` as a raw filesystem
path (e.g. `/Users/foo/project`) instead of a proper `file://` URI (e.g.
`file:///Users/foo/project`).
This caused the vscode-eslint server's `workingDirectory: { mode: "auto"
}` to fail when resolving the workspace root, falling back to the linted
file's directory as the working directory. As a result,
`eslint-import-resolver-typescript` could not locate `tsconfig.json`,
breaking path alias resolution for rules like `import/order` — producing
different lint results compared to VS Code.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A or Added/Fixed/Improved ...
This PR introduces native LSP support for Bash by integrating
`bash-language-server`. Combined with the existing Tree-sitter grammar,
Zed now provides a complete, out-of-the-box development experience for
shell scripting.
The implementation is very similar to other npm-managed language
servers. With `shellcheck` installed, standard LSP features—including
diagnostics, code actions, go-to-definition, find-references, and code
completion—work as expected.
Since I am not a frequent user of Bash, I have intentionally limited
this implementation to a standard, "out-of-the-box" setup. I lack the
hands-on experience to identify specific pain points or advanced LSP
features that might require custom integration, so I've avoided adding
any speculative or specialized configurations, especially within the
`LspAdapter` trait.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#51917
Release Notes:
- Added built-in language server support for Bash
---------
Co-authored-by: Finn Evers <finn@zed.dev>
Powershell does not support eval, furthermore pwsh is also a
"powershell" shell for micromamba.
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [X] Unsafe blocks (if any) have justifying comments
- [X] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- Fixes micromamba powershell activation
## Context
Previously the Run Debugger gutter arrow would fail silently when the
Cargo.toml had garbage lines such as “asdfasdf”. This fix makes it so
that the error is detected and bubbles up to the editor, which will
notify the user with a toast diagnostic.
Closes#46716
## Fix
https://github.com/user-attachments/assets/2e9ac7e9-1306-4607-a762-457131473572
## How to Review
Small PR - focused on four different files:
In - `crates/languages/src/rust.rs`:
- `target_info_from_abs_path()` - The function signature was changed
from `Option<(Option<TargetInfo>, Arc<Path>)>` to
`Result<Option<(Option<TargetInfo>, Arc<Path>)>>`. A condition was added
to ensure that if the Cargo metadata command is unsuccessful, the
function returns an error instead of causing an EOF error while
deserializing the stdout of the command.
- `build_context()` - Added a `?` in `target_info_from_abs_path(path,
project_env.as_ref()).await` in order to return the error.
In - `crates/project/src/task_store.rs`:
- `local_task_context_for_location()` and
`remote_task_context_for_location()` - The functions signatures were
changed from `Task<Option<TaskContext>>` to
`Task<anyhow::Result<Option<TaskContext>>>` for the purpose of
propagating the error.
In - `crates/editor/src/editor_tests.rs`:
- `build_tasks_context()` - The function signature was changed from
`Task<Option<TaskContext>>` to
`Task<anyhow::Result<Option<TaskContext>>>` .
- `toggle_code_actions()` - In case `build_tasks_context()` fails, the
functions notifies the error to the user as a Toast notification.
In - `crates/editor/src/runnables.rs`:
- Since `build_tasks_context()` and
`task_store.task_context_for_location()` now return a Result, the
callers` spawn_nearest_task() `and `task_context()` were modified. The
resulting Result types are transformed to match the expected return
types of `TaskContext` and `Task<Option<TaskContext>>`
Two new tests were added. The first, `target_info_from_abs_path_failed`
in `crates/languages/src/rust.rs`, checks if the system properly catches
the error. The second,
`test_toggle_code_actions_build_tasks_context_error_notifies` in
`crates/editor/src/editor_tests.rs`, confirms that the editor triggers
the expected error notification.
## Self-Review Checklist
- [X] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [X] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [X] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- Fixed the error: Run Debugger failing silently due to invalid
Cargo.toml content
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
No, sadly, the title is not a typo. See
https://www.githubstatus.com/incidents/zsg1lk7w13cf for the context.
I'll read with joy and popcorn through that root cause analysis.
It makes literally zero sense what happened here, but for some completly
bonkers reason GitHub completely messed up the merge queue with
https://github.com/zed-industries/zed/pull/54632.
I have no idea how it happened. It makes literally zero sense. A PR
going into the merge queue should have the same LoC when getting out of
it. GitHub obviously does not check this. GitHub causes extra work with
a feature that is supposed to save time.
Thanks, I guess.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR brings back the button to filter remote branches when accessing
the title bar's branch picker with the mouse. It was unintentionally
removed when we introduced the new worktree picker.
Release Notes:
- N/A
Uses tree-sitter indent queries to create a pseudo-scope, since access
modifiers are single-node in thetree-sitter grammar.
The @outdent capture truncates the parent { } indent range at the access
specifier, keeping it at the same level as the class keyword and the
pseudo-scopes from stacking.
The @outdent range selects siblings so we don't outdent the access
specifiers themselves, since screenshots from the reference issue seem
to show that at least one interested party does not prefer outdented
access modifiers, and also it seemed like less of a departure from
existing design.
Also, there are probably more tests than needed because this is my first
time writing treesitter queries and I wanted to triple-guess myself.
Quite open too feedback on which ones are more valuable.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#53175
Release Notes:
- Improves handling of indentation after C++ access modifiers
Shorthand methods (`methodName() {}`) inside nested object literals were
not shown in the Outline panel. The outline query only captured
method_definition when it was a direct child of a variable_declarator's
object, so nested objects (e.g. `deep: { subFn() {} }`) were missed.
Extended the outline query to match method_definition in any object
node, not just top-level variable_declarator objects. Applied the fix to
TypeScript, JavaScript, and TSX outline definitions. Added tests for the
issue reproduction and edge cases.
Supporting evidence:
<img width="1352" height="812" alt="image"
src="https://github.com/user-attachments/assets/64868a70-abd3-4935-9c03-4c809b55262b"
/>
Fixes#48711
Release Notes:
- Fixed nested object methods not appearing in the Outline panel for
JavaScript and TypeScript files
Closes#47926
## Summary
When using a uv (or Poetry/PDM) workspace with multiple subprojects,
Python LSP servers (Pyright, Ruff, ty, etc.) are initialized with the
subproject directory as their workspace folder instead of the workspace
root. This happens because `PyprojectTomlManifestProvider::search()`
returns the first (innermost)
`pyproject.toml` found walking up the directory tree.
For example, in a uv workspace like:
main-project/
├── pyproject.toml # workspace root with [tool.uv.workspace]
├── uv.lock
├── packages/
│ └── project-api/
│ └── pyproject.toml # subpackage
└── projects/
└── project-a/
└── pyproject.toml # subpackage
Opening a file in `packages/project-api/` would register
`packages/project-api/` as the LSP workspace folder instead of
`main-project/`.
## Approach
The fix uses lockfile existence as a heuristic to detect workspace
roots. The updated `search()` method walks all ancestors (similar to
`CargoManifestProvider`) and:
- Tracks the **innermost** `pyproject.toml` as a fallback
- Tracks the **outermost** `pyproject.toml` that has a sibling lockfile
(`uv.lock`, `poetry.lock`, `pdm.lock`, or `Pipfile.lock`)
- Returns the outermost workspace root if found, otherwise falls back to
the innermost
This works within the existing `ManifestDelegate` interface (existence
checks only, no file content reading).
| Scenario | Result |
|---|---|
| uv workspace (root `pyproject.toml` + `uv.lock`) | Returns workspace
root |
| Poetry workspace (root `pyproject.toml` + `poetry.lock`) | Returns
workspace root |
| Simple project (single `pyproject.toml`, no lockfile) | Returns
project dir (unchanged) |
| Independent subprojects (no lockfile at any level) | Returns each
project's own dir (unchanged) |
Since the manifest provider is set at the Python **language** level,
this fix applies to all Python LSP servers (Pyright, Ruff, ty, etc.).
## Test plan
- [x] Added unit tests for `PyprojectTomlManifestProvider` covering all
scenarios above
- [x] Existing integration test
`test_running_multiple_instances_of_a_single_server_in_one_worktree`
passes (independent subprojects without lockfiles)
- [x] `cargo check -p languages` compiles cleanly
- [x] Manual testing with a real uv workspace (Pyright and Ruff both
receive correct workspace root)
Release Notes:
- Fixed Python LSP servers (Pyright, Ruff, etc.) using the wrong
workspace folder in uv/Poetry/PDM workspaces with multiple subprojects.
This fixes#53819.
JSON schema downloads were still going through the JSON language server
without picking up Zed's configured proxy. On networks that require the
proxy, that made schema fetches fail even though the rest of the app
could connect normally.
This passes the proxy setting through to the JSON language server
configuration so schema requests follow the same network path as the
rest of Zed.
## Test plan
- `rustfmt --edition 2024 crates/languages/src/json.rs`
- `git diff --check -- crates/languages/src/json.rs`
Release Notes:
- Fixed JSON schema downloads ignoring Zed's proxy setting.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- Added the option for highlights from languages to specify fallbacks.
That means that if you have a pattern with the captures `@second.capture
@first.capture`, Zed will first try resolving a highlight from your
theme for the code fragment using the first capture, then look for the
second capture if no match for the first capture could be found.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
