Ported `label_for_symbol` logic directly from the basedpyright adapter
without adjustments.
Given Python's dynamic nature, the current implementation provides
sufficient coverage. No further modifications are needed for now.
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Fixed missing syntax highlighting in symbol search when using the ty
language server.
Closes https://github.com/zed-industries/zed/issues/51240
We don’t parse bsn as embedded Rust anymore. We expect bsn to get its
own Tree-sitter implementation in the future, which should improve this.
This fixes broken syntax highlighting for string literals. See line 66
in the comparison below.
<img width="2560" height="1440" alt="image"
src="https://github.com/user-attachments/assets/230ae057-f315-4290-8f51-bcd21e6557d7"
/>
Release Notes:
- N/A
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
## Summary
Angle brackets in TSX (`<`, `>`, `/>`, `</`) are always paired with JSX
tag syntax — they don't indicate bracket nesting depth — so rainbow
colorization adds noise without useful information.
This mirrors #46808, which applied the same fix to the HTML extension.
## Changes
- Added `(#set! rainbow.exclude)` to all three angle bracket patterns in
`crates/languages/src/tsx/brackets.scm`
## Before / After
Before: angle brackets in JSX tags receive rainbow colors alongside
`{}`, `()`, `[]`, making every tag visually noisy.
After: only `{}`, `()`, and `[]` receive rainbow colors — angle brackets
are excluded, matching the HTML extension behavior.
> Screenshots: I don't have a built copy of Zed handy to attach — happy
to add one if a maintainer needs it before merging.
Release Notes:
- Removed rainbow bracket colorization for angled brackets within TSX.
Run `pylsp --version` via `delegate.try_exec()` in both branches of
`PyLspAdapter::check_if_user_installed` before returning the binary. If
execution fails (broken shebang, missing interpreter, etc.), log a
warning and return None so the system falls through gracefully instead
of surfacing an error dialog.
This matches the existing validation pattern used by TyLspAdapter and
RuffLspAdapter in their `fetch_server_binary` implementations.
No idea if this closes an issue but it sure was annoying on a system
where I deleted the pylsp environment I had. It surprised me too since I
had pylsp disabled in settings.
Release Notes:
- Fixed detection of when `pylsp` is not installed properly on a user's
system so that it doesn't get launched as an LSP when it doesn't exist.
I did a search for `/^line_comments = .*[^\s\[]"/` to identify these 3
languages:
- Git Commit
- Go Mod
- Go Work
that don't add/remove a trailing space for inline comments. I couldn't
find any indication that the absence of the trailing space is due to any
peculiarity of these languages.
---
For Git Commit, I should note that (strictly speaking) the comment
character is a single `#` without a trailing space, as Git removes any
line starting with the default comment character (`#`) (see
https://git-scm.com/docs/git-config#Documentation/git-config.txt-corecommentChar).
But I believe this change only affects whether `editor::ToggleComments`
adds/removes the space, and not how the file is syntax highlighted. So
for aesthetics and consistency, it should be better to add/remove the
trailing space.
---
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Add/remove a space when toggling inline comments in Git Commit and Go
Mod/Work languages
This will help with test times (in some cases), as nextest cannot figure
out whether a given rdep is actually an alive edge of the build graph
Closes #ISSUE
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [ ] Done a self-review taking into account security and performance
aspects
- [ ] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A
Closes#50619
In the conda activation script building procedure, Zed currently
performs a file check for the conda executable on the client side. When
in remote development, this check always fails because the file exists
on the remote host, not the local machine. Since `pet` already handles
existence checks, removing this redundant check allows the activation to
proceed. It is also better to let any potential issues (like
permissions) show up in the terminal rather than silently skipping the
activation.
This addresses the root cause for remote development, which is different
from the approach in #50715 that focuses on shell hooks.
**The video recording**
https://github.com/user-attachments/assets/62967351-e3c5-4814-aec4-b2332940e7e3
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Fixed conda environment not auto-activating in the terminal during
remote development sessions.
gopls reports Go `const` declarations as `variable` with the `readonly`
modifier. Add a Go-specific semantic token rule to map this to the
`constant` theme style, matching VS Code's behavior.
<img width="465" height="32" alt="image"
src="https://github.com/user-attachments/assets/e0bc8a60-2275-4f81-9185-8b86c51d3d08"
/>
Closes#50642
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
`.cppm` is the widely used extension for C++20 module interface units,
supported by MSVC, Clang, and GCC. Currently Zed doesn't recognize it as
C++, so users get no syntax highlighting or LSP support.
Changes:
`crates/languages/src/cpp/config.toml`: add cppm to path_suffixes
`crates/theme/src/icon_theme.rs`: add cppm to the C++ icon matcher
https://github.com/search?q=path%3A*.cppm&type=code
Release Notes:
- N/A
The purpose of `register_available_lsp_adapter()` is to allow language
servers to be reused across multiple languages. Since adapters like
`ty`, `pylsp`, and `pyright` are specific to Python, there is no need to
register them for other languages. Additionally, registering them
directly to the global `LanguageRegistry` results in negligible resource
consumption.
We can then use the default settings to control the default language
server for Python, as referenced here:
9c9337a802/assets/settings/default.json (L2119-L2130)
Additionally, the documentation for Python has been updated to clarify
that the `"..."` syntax does not mean "keep the rest at default," but
rather "include all other available servers."
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing (no sure how to add test for this)
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Move general type identifier rules before class-specific ones to ensure
proper precedence in the syntax highlighting query.
Closes#49226.
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Fixed an issue where class names were not highlighted correctly in
JavaScript files
Closes#47086
This PR detects completion items ending with `=` (which typically
represent keyword arguments in function calls provided by
`Pyright`/`BasedPyright`/`pylsp`) and assigns them the highest sorting
priority.
This ensures that when a user is filling out function arguments, the
named parameters appear at the top of the list, rather than being buried
mixed with other symbols.
After fix:
<img width="786" height="460" alt="image"
src="https://github.com/user-attachments/assets/75e94b0f-a2e7-4876-b9bd-02ad98cc8c50"
/>
> **Note on Sorting:** Currently, these named arguments will be sorted
alphabetically by label. Preserving the original order of the function
definition would be ideal, but it requires information not currently
available in this logical block. Insights on how to retrieve the
definition order would be appreciated.
> **Note on other LSPs:**
> * **`ty`**: Already provides well-sorted completions natively, so no
intervention is required.
Release Notes:
- Improved completion order for Python-based LSPs
Highlight files ending in `.mdc` as Markdown.
The `.mdc` extension is used by Cursor for its Markdown-based rule files
(`.cursor/rules/*.mdc`). These files are standard Markdown with optional
YAML frontmatter, which the existing Markdown grammar already handles
well. Adding `.mdc` to the recognized suffixes ensures proper syntax
highlighting out of the box.
This was requested during review of the agnix extension PR
([zed-industries/extensions#4743](https://github.com/zed-industries/extensions/pull/4743))
by @MrSubidubi as the preferred approach over defining a custom MDC
language in an extension.
Release Notes:
- Added `.mdc` as a recognized Markdown file extension.
HTML character references like `·`, `'`, and `{` are
correctly parsed by tree-sitter as named nodes
(`html_character_reference` in TSX/JavaScript, `entity` in HTML), but no
highlight query captures them. This means they render as plain,
unhighlighted text in the editor.
This PR adds one-line highlight captures for each:
- **TSX** (`crates/languages/src/tsx/highlights.scm`):
`(html_character_reference) @string.special`
- **JavaScript** (`crates/languages/src/javascript/highlights.scm`):
`(html_character_reference) @string.special`
- **HTML** (`extensions/html/languages/html/highlights.scm`): `(entity)
@string.special`
`@string.special` is already styled by all built-in themes (One Dark,
Ayu, Gruvbox, etc.), so no theme changes are needed.
Release Notes:
- Added syntax highlighting for HTML character references (`·`,
`'`, `{`, etc.) in TSX, JavaScript, and HTML files.
This allows definitions to use a different highlight than function
calls.
Release Notes:
- go: Add definition highlights for functions, methods, and types
GeoJSON is a popular geospatial data interchange format, standardised as
[RFC 7946](https://datatracker.ietf.org/doc/html/rfc7946). Because all
GeoJSON files are valid JSON files, they can be highlighted using Zed's
existing JSON language support.
This change adds `geojson` as a recognised path suffix, so GeoJSON files
automatically open as JSON and get the standard JSON syntax
highlighting.
Before and after screenshots:
<img width="1748" height="755" alt="geojson"
src="https://github.com/user-attachments/assets/40199248-1ce5-451e-9200-5b2f012b865f"
/>
Release notes:
- Added automatic syntax highlighting for GeoJSON files
Release Notes:
- Fixed prevent shell command injection in conda environment activation
The conda environment name was directly interpolated into the shell
command without proper escaping, which could allow command injection
if the environment name contained malicious shell metacharacters.
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
Here's some backstory:
* on macOS, @cole-miller and I noticed that since roughly Oct 2025, due
to some changes to latest macOS Tahoe, for any spawned child process we
needed to reset Mach exception ports
(https://github.com/zed-industries/zed/issues/36754 +
6e8f2d2ebe)
* the changes in that PR achieve that via `pre_exec` hook on
`std::process::Command` which then abandons `posix_spawn` syscall for
`fork` + `execve` dance on macOS (we tracked it down in Rust's std
implementation)
* as it turns out, `fork` + `execve` is pretty expensive on macOS
(apparently way more so than on other OSes like Linux) and `fork` takes
a process-wide lock on the allocator which is bad
* however, since we wanna reset exception ports on the child, the only
official way supported by Rust's std is to use `pre_exec` hook
* posix_spawn on macOS exposes this tho via a macOS specific extension
to that syscall `posix_spawnattr_setexceptionports_np` but there is no
way to use that via any standard interfaces in `std::process::Command`
* thus, it seemed like a good idea to instead create our own custom
Command wrapper that on non-macOS hosts is a zero-cost wrapper of
`smol::process::Command`, while on macOS we reimplement the minimum to
achieve `smol::process::Command` with `posix_spawn` under-the-hood
Notably, this changeset improves git-blame in very large repos
significantly.
Release Notes:
- Fixed performance spawning child processes on macOS by always forcing
`posix_spawn` no matter what.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Closes#30938
Release Notes:
- Fixed: Unable to load relative path JSON schema for YAML validation
(#30938)
This patch follows the vscode LSP client logic, see
[`jsonClient.ts`](cee904f80c/extensions/json-language-features/client/src/jsonClient.ts (L768-L770)).
The `url` of the JSON schemas settings and the YAML schemas settings
should be resolved to an absolute path in the LSP client when it is
submitted to the server.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Add support for detecting Go files that can be executed directly via
shebang-style comments (e.g., '// usr/bin/env go run "$0" "$@"; exit
"$?"').
This allows Zed to recognize Go scripts with first-line comments
containing 'go run' as executable Go files, similar to how other
languages detect shebangs or mode lines.
Reference: https://stackoverflow.com/q/7707178/1458343
Release Notes:
- Improved: Go language detection now recognizes executable Go scripts
with first-line 'go run' comments.
Fixes#48357
## Summary
- Bumps `tree-sitter-go` from `0.23` to `0.25`
- This fixes wrong syntax highlighting with chained indexing in Go (e.g.
`a[b][c] = 0` being incorrectly parsed as a type instantiation
expression instead of an index expression)
- The upstream fix
([tree-sitter/tree-sitter-go#160](https://github.com/tree-sitter/tree-sitter-go/issues/160))
landed in v0.25.0, which gives index expressions a higher dynamic
precedence over type instantiation expressions
- Updated `runnables.scm` to account for the new `statement_list` node
that wraps statements inside blocks in tree-sitter-go 0.25
## Test plan
- [x] `cargo test -p languages` — all 47 tests pass
- Verified that existing Go runnables queries (table tests, subtests,
test detection) work with the updated grammar
Release Notes:
- Fixed wrong syntax highlighting with chained indexing in Go (e.g.
`a[b][c]`) by bumping tree-sitter-go to 0.25
This changes the highlight capture for preprocessor directives from
`@keyword.directive` to `@preproc` in both C and C++.
PR #44043 changed C from `@keyword` to `@keyword.directive` for
consistency with C++, but `@keyword.directive` is still semantically
wrong. Preprocessor directives are not language keywords — they are
instructions to a separate preprocessing phase that runs before
compilation.
Using `@preproc` reflects this distinction and allows themes to style
them independently from actual language keywords like `const`,
`struct`,`if`, etc. This is consistent with how editors like CLion
handle preprocessor directives.
Before:
<img width="710" height="653" alt="before"
src="https://github.com/user-attachments/assets/5c02fc06-bc19-4112-ae53-ad72eb8044e3"
/>
After:
<img width="710" height="653" alt="after"
src="https://github.com/user-attachments/assets/2490e796-7286-4fbb-81b0-387f551cde8f"
/>
Release Notes:
- C/C++: Syntax highlighting for preprocessor directives can now be
tweaked with @preproc capture group.
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
Exclude special [TestMain](https://pkg.go.dev/testing#hdr-Main) function
from Go runnables.
Release Notes:
- Excluded `TestMain` function from Go runnables.
Fixes an issue where syntax highlighting would be incorrect in certain
cases for JS, because of duplicate keyword definitions.
Release Notes:
- Fixed issue where certain keywords were incorrectly highlighted in JS
files
Some language servers include local symbols (e.g., local variables,
parameters) in workspace symbol results. Without the `containerName`
information, these symbols lack context information, making it difficult
to distinguish them from top-level definitions and hindering efficient
symbol lookup.
This change exposes the `container_name` field from LSP
[`SymbolInformation`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#symbolInformation)
to the extension API, allowing language server extensions to access
`symbol.container_name` in `label_for_symbol` and provide meaningful
context when rendering symbol labels.
Note: The `container_name `field is added to all extension API versions
because they seem to share the same underlying Rust types via wasmtime
bindgen. The field is optional, so existing extensions would remain
compatible as far as I understand.
Closes #ISSUE
Release Notes:
- Added `container_name` field to `lsp::Symbol`, accessible via the
extension API's `label_for_symbol` function
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Part of #7450
Big thanks to @macmv for pushing this forwards so much!
Rebased version of https://github.com/zed-industries/zed/pull/39539 as
working on an in-org branch simplifies a lot of things for us)
Release Notes:
- Added LSP semantic tokens highlighting support
---------
Co-authored-by: Neil Macneale V <neil.macneale.v@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This language is used for the keymap editor and should not be selectable
for normal files. Hence, removing it here from the language selector
Release Notes:
- Fixed an issue where the Zed keybinding context would show up as a
language in the language selector.
## Problem
The existing tree-sitter queries for type imports required both name and
alias fields to match. This caused `import type { Foo }` and `import {
type Foo }` to fall back to the generic identifier/variable highlighting
instead of being colored as types.
- `import type { Foo }` → **NOT matched** (no alias)
- `import { type Foo }` → **NOT matched** (no alias)
- `import type { Foo as Bar }` → Matched ✓
- `import { type Foo as Bar }` → Matched ✓
## Solution
Split the patterns to handle name and alias captures independently.
~## Disclaimer~
~DEBUGGING AND IMPLEMENTATION WAS DONE WITH **AI ASSISTANCE**.~
~**THE FIX HAS NOT BEEN TESTED** - I HAVE NOT COMPILED FROM SOURCE~
- @KyleBarton built from source and verified
Release Notes:
- Fixed typescript type import highlighting
## Summary
This PR extends the `always_allow` tool permission patterns to work with
Nushell, Elvish, and Rc shells. Previously, these shells were
incorrectly excluded because they don't use `&&`/`||` operators for
command chaining. However, brush-parser can safely parse their command
syntax since they all use `;` for sequential execution.
## Changes
- Add `ShellKind::Nushell`, `ShellKind::Elvish`, and `ShellKind::Rc` to
`supports_posix_chaining()`
- Split `ShellKind::Unknown` into `ShellKind::UnknownWindows` and
`ShellKind::UnknownUnix` to preserve platform-specific fallback behavior
while still denying `always_allow` patterns for unrecognized shells
- Add comprehensive tests for the new shell support
- Clarify documentation about shell compatibility
## Shell Notes
- **Nushell**: Uses `;` for sequential execution. The `and`/`or`
keywords are boolean operators on values, not command chaining.
- **Elvish**: Uses `;` to separate pipelines. Does not have `&&` or `||`
operators. Its `and`/`or` are special commands operating on values.
- **Rc (Plan 9)**: Uses `;` for sequential execution and `|` for piping.
Does not have `&&`/`||` operators.
## Security
Unknown shells still return `false` from `supports_posix_chaining()`, so
`always_allow` patterns are denied for safety when we can't verify the
shell's syntax.
(No release notes because granular tool permissions are still
feature-flagged.)
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
