The watcher had been broken for some time, but became even more broken
after the recent move of the queries.
This PR restores the reloading behavior for debug builds so that
languages are reloaded once a scheme file is changed.
Release Notes:
- N/A
This extracts a `language_core` crate from the existing `language`
crate, and creates a `grammars` data crate. The goal is to separate
tree-sitter grammar infrastructure, language configuration, and LSP
adapter types from the heavier buffer/editor integration layer in
`language`.
## Motivation
The `language` crate pulls in `text`, `theme`, `settings`, `rpc`,
`task`, `fs`, `clock`, `sum_tree`, and `fuzzy` — all of which are needed
for buffer integration (`Buffer`, `SyntaxMap`, `Outline`,
`DiagnosticSet`) but not for grammar parsing or language configuration.
Extracting the core types lets downstream consumers depend on
`language_core` without pulling in the full integration stack.
## Dependency graph after extraction
```
language_core ← gpui, lsp, tree-sitter, util, collections
grammars ← language_core, rust_embed, tree-sitter-{rust,python,...}
language ← language_core, text, theme, settings, rpc, task, fs, ...
languages ← language, grammars
```
## What moved to `language_core`
- `Grammar`, `GrammarId`, and all query config/builder types
- `LanguageConfig`, `LanguageMatcher`, bracket/comment/indent config
types
- `HighlightMap`, `HighlightId` (theme-dependent free functions
`highlight_style` and `highlight_name` stay in `language`)
- `LanguageName`, `LanguageId`
- `LanguageQueries`, `QUERY_FILENAME_PREFIXES`
- `CodeLabel`, `CodeLabelBuilder`, `Symbol`
- `Diagnostic`, `DiagnosticSourceKind`
- `Toolchain`, `ToolchainScope`, `ToolchainList`, `ToolchainMetadata`
- `ManifestName`
- `SoftWrap`
- LSP data types: `BinaryStatus`, `ServerHealth`,
`LanguageServerStatusUpdate`, `PromptResponseContext`, `ToLspPosition`
## What stays in `language`
- `Buffer`, `BufferSnapshot`, `SyntaxMap`, `Outline`, `DiagnosticSet`,
`LanguageScope`
- `LspAdapter`, `CachedLspAdapter`, `LspAdapterDelegate` (reference
`Arc<Language>` and `WorktreeId`)
- `ToolchainLister`, `LanguageToolchainStore` (reference `task` and
`settings` types)
- `ManifestQuery`, `ManifestProvider`, `ManifestDelegate` (reference
`WorktreeId`)
- Parser/query cursor pools, `PLAIN_TEXT`, point conversion functions
## What the `grammars` crate provides
- Embedded `.scm` query files and `config.toml` files for all built-in
languages (via `rust_embed`)
- `load_queries(name)`, `load_config(name)`,
`load_config_for_feature(name, grammars_loaded)`, and `get_file(path)`
functions
- `native_grammars()` for tree-sitter grammar registration (behind
`load-grammars` feature)
## Pre-cleanup (also in this PR)
- Removed unused `Option<&Buffer>` from
`LspAdapter::process_diagnostics`
- Removed unused `&App` from `LspAdapter::retain_old_diagnostic`
- Removed `fs: &dyn Fs` from `ToolchainLister` trait methods
(`PythonToolchainProvider` captures `fs` at construction time instead)
- Moved `Diagnostic`/`DiagnosticSourceKind` out of `buffer.rs` into
their own module
## Backward compatibility
The `language` crate re-exports everything from `language_core`, so
existing `use language::Grammar` (etc.) continues to work unchanged. The
only downstream change required is importing `CodeLabelExt` where
`.fallback_for_completion()` is called on the now-foreign `CodeLabel`
type.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Tom Houlé <tom@tomhoule.com>
- zed-extensions/elixir#61 renames `HEEX` to `HEEx`; to prevent any
disruptions from that change, this adds the correct name alongside a
settings migration
- zed-extensions/elixir#101 adds support for `EEx` templates; this sets
the default language server to be the same as that of `Elixir` and
`HEEx`
This also adds a few more extensions that should be recognized as `HEEx`
files
Release Notes:
- N/A
---------
Co-authored-by: Finn Evers <finn@zed.dev>
## Context
Closes#52391
gopls sends semantic tokens for format args with [format] modifier.
Without a simple support for there is no special highlighting for format
args like `%s`. Its a simple change inside
`go/semantic_token_rules.json` that makes this a default behavior.
Currently (on 0.229 preview):
<img width="1136" height="675" alt="Screenshot 2026-03-25 at 11 34 57"
src="https://github.com/user-attachments/assets/cd3d9a52-6740-47b5-8f05-02514cb4f9df"
/>
After fix:
<img width="1136" height="675" alt="Screenshot 2026-03-25 at 11 58 37"
src="https://github.com/user-attachments/assets/5ec4277b-39c1-4fe1-bed5-8a6fa63c18c9"
/>
## Self-Review Checklist
<!-- Check before requesting review: -->
- [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:
- gopls: Add semantic token rule for format string interpolations
## Summary
- Added `TarBz2` variant to `AssetKind` enum for `.tar.bz2` / `.tbz2`
archives
- Implemented `extract_tar_bz2` using the `bzip2` feature of
`async-compression` (already a workspace dependency, just enabled the
feature flag)
- Wired up both streaming and file-based extraction paths in
`github_download.rs`
- Added `.tar.bz2` / `.tbz2` URL detection in both
`LocalExtensionArchiveAgent` and `LocalRegistryArchiveAgent`
This unblocks ACP registry entries (like Goose) that only ship
`.tar.bz2` archives.
Reference: https://github.com/block/goose/issues/8047
## Test plan
- [ ] Verify `cargo check` and `clippy` pass (confirmed locally)
- [ ] Test downloading an ACP agent that ships a `.tar.bz2` archive
(e.g., Goose)
- [ ] Verify existing `.tar.gz` and `.zip` agent downloads still work
Release Notes:
- Added support for `.tar.bz2` archives in ACP agent server downloads,
unblocking registry entries like Goose that only ship bzip2-compressed
tarballs.
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Many editors such as vim and emacs support "modelines", a comment at the
beginning of the file that allows the file type to be explicitly
specified along with per-file specific settings
- The amount of configurations, style and settings mapping cannot be
handled in one go, so this opens up a lot of potential improvements.
- I left out the possiblity to have "zed" specific modelines for now,
but this could be potentially interesting.
- Mapping the mode or filetype to zed language names isn't obvious
either. We may want to make it configurable.
This is my first contribution to zed, be kind. I struggled a bit to find
the right place to add those settings. I use a similar approach as done
with editorconfig (merge_with_editorconfig). There might be better ways.
Closes#4762
Release Notes:
- Add basic emacs/vim modeline support.
Supersedes #41899, changes:
- limit reading to the first and last 1kb
- add documentation
- more variables handled
- add Arc around ModelineSettings to avoid extra cloning
- changed the way mode -> language mapping is done, thanks to
`modeline_aliases` language config
- drop vim ex: support
- made "Local Variables:" handling a separate commit, so we can drop it
easily
- various code style improvements
---------
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
## Context
Recently, we put bsn in the list of "macros to not reparse as rust"
(#51353).
We have since updated tree-sitter-rust to better handle the `@"string"`,
`:"string"`, etc cases, and can un-list bsn from the special casing.
on main, the highlighting currently looks like this for `bsn` and for
`not` (represents "other macros"). Note the `:"player.bsn"` string is
re-parsed as rust tokens.
<img width="1728" height="1084" alt="Screenshot 2026-03-23 at 9 33
35 AM"
src="https://github.com/user-attachments/assets/94ea5a6d-228b-44dd-857b-c41edcbd9af0"
/>
This pr, plus the tree-sitter-rust updates results in better handling by
default.
<img width="1728" height="1084" alt="Screenshot 2026-03-23 at 11 38
47 AM"
src="https://github.com/user-attachments/assets/fb6f71e3-7bcf-4c06-8e84-ce0823010b2e"
/>
Release Notes:
- N/A
## Context
Zed's semantic token highlighting does not cover all token types
returned by language servers, so the highlighting looks fairly primitive
compared with tree-sitter highlighting, especially for Python language
servers. This PR adds some global and Python-specific rules for better
highlighting.
I need to admit that the built-in Python language servers currently have
weak semantic highlighting implementations. Pylance, the closed-source
Python language server from Microsoft, provides the best highlighting
for now, but I think ty will do better, even though it still has a long
way to go.
## How to Review
Basically, this is a rule-adding change. Some rules are made global, and
some are made Python-specific.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [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:
- Improved semantic token highlighting for parameters and Python
## Context
Fixes https://github.com/zed-industries/zed/issues/51921
`await` was grouped under the generic `@keyword` capture in the
tree-sitter highlights queries for JavaScript, TypeScript, and TSX. It
should be `@keyword.control`, since it's a control flow keyword — same
as `return`, `yield`, `throw`, `break`, etc., which were already
correctly classified.
This aligns Zed's highlighting with VSCode's behavior, where `await` is
tokenized as `keyword.control`.
## How to Review
Three single-line moves across highlights files — `await` removed from
the `@keyword` list, added to the `@keyword.control` list:
1. `crates/languages/src/javascript/highlights.scm`
2. `crates/languages/src/typescript/highlights.scm`
3. `crates/languages/src/tsx/highlights.scm`
## 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)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Image :
<img width="3072" height="1728" alt="Screenshot from 2026-03-20
22-15-40"
src="https://github.com/user-attachments/assets/9e849d4d-dad4-4fa0-b3b8-8e633f96c585"
/>
Release Notes:
- Fixed `await` keyword not being highlighted as `keyword.control` in
JavaScript, TypeScript, and TSX files
---------
Co-authored-by: Kunall Banerjee <hey@kimchiii.space>
This PR updates the pet dependency to incorporate performance
improvements from upstream.
Related Upstream Changes:
- Issue: microsoft/python-environment-tools#369
- PR: microsoft/python-environment-tools#370
Updating pet reduces toolchain discovery time in WSL environments,
specifically when Conda is installed on the host Windows system. In my
testing, the time from clicking the toolchain button to the list
appearing was reduced by approximately 2 seconds.
While this is a notable improvement, discovery in WSL remains slightly
slower than in native development or remote Linux environments, where
toolchains are typically loaded near-instantaneously.
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 (no need)
- [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:
- Improved python toolchain discovery under WSL environment
Closes#51620
gopls requires more specific initialization for semantic tokens that
other language-servers for reasons that aren't entirely clear to me, it
is however a small fix to make it work. still trying to track down other
malfunctioning language servers in the semantic token realm, so if you
have suggestions let me know.
original behavior (on nightly v0.229):
<img width="1784" height="1123" alt="nightly_behavior"
src="https://github.com/user-attachments/assets/5d976b34-2720-425c-8617-800291862909"
/>
updated behavior:
<img width="1784" height="1124" alt="fix_applied"
src="https://github.com/user-attachments/assets/17c528b9-fea8-4309-9306-44673afc9fc3"
/>
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:
- gopls: fixed semantic token support with gopls.
There is no highlight for block quotes continued on multiple lines
Currently, the ">" on lines 2 and 3 are not highlighted in the same way
as line 1
<img width="291" height="73" alt="image"
src="https://github.com/user-attachments/assets/7a2f2e25-6ee1-40a6-8833-f06ca7ee6ba9"
/>
After this PR,
<img width="249" height="75" alt="image"
src="https://github.com/user-attachments/assets/34a2971f-8061-4d92-ac45-a8043d5d0566"
/>
for this input
```md
> abcd
>
> abcd
```
tree-sitter produces this
```
(document [0, 0] - [3, 0]
(section [0, 0] - [3, 0]
(block_quote [0, 0] - [3, 0]
(block_quote_marker [0, 0] - [0, 2])
(paragraph [0, 2] - [1, 1]
(inline [0, 2] - [0, 6])
(block_continuation [1, 0] - [1, 1]))
(block_continuation [2, 0] - [2, 2])
(paragraph [2, 2] - [3, 0]
(inline [2, 2] - [2, 6])))))
```
the screenshots in #43043 also show this issue
Release Notes:
- Fixed highlighting of block quotes continued over multiple lines in
markdown files
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.
## 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:
https://github.com/zed-industries/zed/blob/2cc3d382bb669629471886c2ea9b43311c525099/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 +
https://github.com/RemiKalbe/zed/commit/6e8f2d2ebe5a93753625a3026aeb996de8cb436b)
* 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>
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.
Finn Evers