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.
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>
This PR extends support to run Go table-test subtests (#35657), handling
tests without explicitly declaring variables for test scenarios.
<img width="611" height="318" alt="go-table-tests"
src="https://github.com/user-attachments/assets/e001b661-b512-4183-b6df-6c25f3af4f27"
/>
Release Notes:
- Improved support to run Go table-test subtests, handling tests without
explicitly declaring variables for test scenarios.
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Improve syntax highlighting of keywords by creating groups for
declarations and import/export.
### Release Notes:
- Highlight declarations with `keyword.declaration`:
- const
- let
- var
- function
- class
- enum
- interface
- type
- Highlight imports and exports with `keyword.import`:
- export
- from
- import
---------
Co-authored-by: Gaauwe Rombouts <mail@grombouts.nl>
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>
Closes#47098
The root cause of this issue is related to how `Poetry` (and the
upstream `pet-poetry` library) handles path hashing. While perhaps it's
an upstream behavior, we can easily fix it on the Zed side.
The related code are
https://github.com/zed-industries/zed/blob/23c7d60f1e9a1f9e4ce1502aad3bf90c8093833e/crates/languages/src/python.rs#L1181-L1211
In my debugging, I found that `worktree_root` takes the form
`/home/user/project`, but `config.workspace_directories` often ends up
as `/home/user/project/`(with a trailing slash). Normally this wouldn't
be an issue, but `Poetry` generates environment names based on the hash
of the absolute path. Since the hashes for `/home/user/project` and
`/home/user/project/` are different, `pet-poetry` fails to find the
environment.
The fix is straightforward: we just need to ensure the trailing `/` is
removed so the hashes match.
Release Notes:
- Fixed poetry environment not discovered on linux
Closes#46701
This ports the fixes from #46442 over to the JavaScript highlights,
which we forgot to do in that PR since the highlights are not shareable
and the fix was only applied to TSX... Hence, porting the fixes here
manually to solve the issue for good.
Release Notes:
- Fixed an issue where JSX components were highlighted too broadly,
causing normal HTML tags to be highlighted as such
This aligns ty's behavior with ruff by checking for binaries in the
following order:
1. venv (from the Python toolchain's bin directory)
2. PATH
3. Zed-installed
Release Notes:
- ty: Added support for using venv-installed binary
