Deals with https://github.com/zed-industries/zed/issues/5259
Highlights brackets with different colors based on their depth.
Uses existing tree-sitter queries from brackets.scm to find brackets,
uses theme's accents to color them.
https://github.com/user-attachments/assets/cc5f3aba-22fa-446d-9af7-ba6e772029da
1. Adds `colorize_brackets` language setting that allows, per language
or globally for all languages, to configure whether Zed should color the
brackets for a particular language.
Disabled for all languages by default.
2. Any given language can opt-out a certain bracket pair by amending the
brackets.scm like `("\"" @open "\"" @close) ` -> `(("\"" @open "\""
@close) (#set! rainbow.exclude))`
3. Brackets are using colors from theme accents, which can be overridden
as
```jsonc
"theme_overrides": {
"One Dark": {
"accents": ["#ff69b4", "#7fff00", "#ff1493", "#00ffff", "#ff8c00", "#9400d3"]
}
},
```
Release Notes:
- Added bracket colorization (rainbow brackets) support. Use
`colorize_brackets` language setting to enable.
---------
Co-authored-by: MrSubidubi <dev@bahn.sh>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: MrSubidubi <finn@zed.dev>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#42922
Release Notes:
- Fixed Correctly highlighting the 'for' keyword in Rust as
keyword.control only in for loops.
- Fixed Highlighting the 'await' keyword in Rust as keyword.control
This makes sure we do not apply the highlights for snake case
identifiers as well as paths for attributes too broadly to all types of
macros, which should make macros much more readable overall whilst
keeping the highlighting for the attribute items.
| Before | After |
| --- | --- |
| <img width="1414" height="958" alt="Bildschirmfoto 2025-08-28 um 00 37
58"
src="https://github.com/user-attachments/assets/1254b9a2-d07a-4be4-9b4f-555a7c640302"
/> | <img width="1414" height="958" alt="Bildschirmfoto 2025-08-28 um 00
37 38"
src="https://github.com/user-attachments/assets/5f6dd66c-5469-4f27-9f1d-0a6e6e8d8085"
/> |
Release Notes:
- rust: Improved highlighting within macros.
Currently shorthand field initializers are not captured the same way as
the full initializers, leading to awkward and mismatching highlighting.
This PR addresses this fact, in addition to capturing new highlights:
- Tags the `!` as part of a macro invocation.
- Tags the identifier part of a lifetime as `@lifetime`.
- Tag module definitions as a new capture group, `@module`.
- Shorthand initializers are now properly tagged as `@property`.
Here's what the current version of Zed looks like:
<img width="596" height="683" alt="image"
src="https://github.com/user-attachments/assets/c9e52d8e-03dc-426b-8545-4fe872b803e0"
/>
With the new highlighting applied:
<img width="596" height="683" alt="image"
src="https://github.com/user-attachments/assets/b7bd9391-9910-456b-8198-6871174d0f4f"
/>
Release Notes:
- Improved highlighting of Rust files, including new highlight groups
for modules and shorthand initializers.
As suggested in https://github.com/zed-industries/zed/pull/34418, this
proposes various changes to language configs to make block comments and
doc-block-style comments more similar. In doing so, it introduces some
breaking changes into the extension schema.
This change is needed to support the changes I'm working on in #34418,
to be able to support `rewrap` in block comments like `/* really long
comment ... */`. As is, we can do this in C-style doc-block comments (eg
`/** ... */`) because of the config in `documentation`, but we can't do
this in regular block comments because we lack the info about what the
line prefix and indentation should be.
And while I was here, I did various other clean-ups, many of which feel
nice but are optional.
I would love special attention on the changes to the schema, version and
related changes; I'm totally unfamiliar with that part of Zed.
**Summary of changes**
- break: changes type of `block_comment` to same type as
`documentation_comment` (**this is the important change**)
- break: rename `documentation` to `documentation_comment` (optional,
but improves consistency w/ `line_comments` and `block_comment`)
- break/refactor?: removes some whitespace in the declaration of
`block_comment` delimiters (optional, may break things, need input; some
langs had no spaces, others did)
- refactor: change `tab_size` from `NonZeroU32` to just a `u32` (some
block comments don't seem to need/want indent past the initial
delimiter, so we need this be 0 sometimes)
- refactor: moves the `documentation_comment` declarations to appear
next to `block_comment`, rearranges the order of the fields in the TOML
for `documentation_comment`, rename backing `struct` (all optional)
**Future scope**
I believe that this will also allow us to extend regular block comments
on newline – as we do doc-block comments – but I haven't looked into
this yet. (eg, in JS try pressing enter in both of these: `/* */` and
`/** */`; the latter should extend w/ a `*` prefixed line, while the
former does not.)
Release Notes:
- BREAKING CHANGE: update extension schema version from 1 to 2, change
format of `block_comment` and rename `documentation_comment`
/cc @smitbarmase
## Context
To support inline values a language will have to implement their own
provider trait that walks through tree sitter nodes. This is overly
complicated, hard to accurately implement for each language, and lacks
proper extension support.
This PR switches to a singular inline provider that uses a language's
`debugger.scm` query field to capture variables and scopes. The inline
provider is able to use this information to generate inlays that take
scope into account and work with any language that defines a debugger
query file.
### Todos
- [x] Implement a utility test function to easily test inline values
- [x] Generate inline values based on captures
- [x] Reimplement Python, Rust, and Go support
- [x] Take scope into account when iterating through variable captures
- [x] Add tests for Go inline values
- [x] Remove old inline provider code and trait implementations
Release Notes:
- debugger: Generate inline values based on a language debugger.scm file
## Context
This PR improves the accuracy of our inline values for Rust/Python. It
does this by only adding inline value hints to the last valid use of a
variable and checking whether variables are valid within a given scope
or not.
We also added tests for Rust/Python inline values and inline values
refreshing when stepping in a debug session.
### Future tasks
1. Handle functions that have inner functions defined within them.
2. Add inline values to variables that were used in inner scopes but not
defined in them.
3. Move the inline value provider trait and impls to the language trait
(or somewhere else).
4. Use Semantic tokens as the first inline value provider and fall back
to tree sitter
5. add let some variable statement, for loops, and function inline value
hints to Rust.
6. Make writing tests more streamlined.
6.1 We should be able to write a test by only passing in variables,
language, source file, expected result, and stop position to a function.
7. Write a test that has coverage for selecting different stack frames.
co-authored-by: Remco Smits \<djsmits12@gmail.com\>
Release Notes:
- N/A
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
- Languages now define their preferred debuggers in `config.toml`.
- `LanguageRegistry` now exposes language config even for languages that
are not yet loaded. This necessitated extension registry changes (we now
deserialize config.toml of all language entries when loading new
extension index), but it should be backwards compatible with the old
format. /cc @maxdeviant
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
This PR uses Tree Sitter to show inline values while a user is in a
debug session.
We went with Tree Sitter over the LSP Inline Values request because the
LSP request isn't widely supported. Tree Sitter is easy for
languages/extensions to add support to. Tree Sitter can compute the
inline values locally, so there's no need to add extra RPC messages for
Collab. Tree Sitter also gives Zed more control over how we want to show
variables.
There's still more work to be done after this PR, namely differentiating
between global/local scoped variables, but it's a great starting point
to start iteratively improving it.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <peterosiewicz@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Cole Miller <m@cole-miller.net>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Kirill <kirill@zed.dev>
#25333 added broader highlighting for identifiers, which broke the
generic query for attribute queries, resulting in these being
highlighted the same as identifiers.
To accomodate for this change, this PR updates the attribute matches to
be more specific.
Additionally, path matches in scoped identifiers are no longer
highlighted as attributes, as seen in the comparison screenshot. Can
revert this if requested.
| Zed Preview | <img width="750" alt="preview"
src="https://github.com/user-attachments/assets/2cd2e830-f510-4adf-8ce9-c41ed6fb157c"
/> |
| --- | --- |
| `main` | <img width="750" alt="main"
src="https://github.com/user-attachments/assets/cbe93186-9afd-4515-bc06-e519fd4ee6af"
/> |
| This PR | <img width="750" alt="pr"
src="https://github.com/user-attachments/assets/68270de8-e083-4fc6-a45e-25d3151acd87"
/> |
The generic match for `token_tree` is needed to recursively match
patterns like `#[cfg(any(test, feature = "test-support"))]` (or at least
I was unable to find a better query here). I tried to validate that this
does not break any other highlights and I believe it does not. However,
I might have still missed something.
Release Notes:
- N/A
Release Notes:
- Fixed issue where `true` and `false` were highlighted as constants,
ignoring the `boolean` highlight defined in themes.
- This fix applies to: C, C++, Go, JSON, JSONC, Python, and Rust.
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
### Overview
This PR improves the existing
[mini.ai‐like](https://github.com/echasnovski/mini.ai) text-object logic
for both “AnyQuotes” (quotes) and “AnyBrackets” (brackets) by adding a
multi‐line fallback. The first pass searches only the current line for a
best match (cover or next); if none are found, we do a multi‐line pass.
This preserves mini.ai's usual “line priority” while ensuring we can
detect pairs that start on one line and end on another.
### What Changed
1. Brackets
- Line-based pass uses `gather_line_brackets(map, caret.row()) `to find
bracket pairs `((), [], {}, <>) `on the caret’s line.
- If that fails, we call `gather_brackets_multiline(map)` to single‐pass
scan the entire buffer, collecting bracket pairs that might span
multiple lines.
- Finally, we apply the mini.ai “**cover or next**” logic
(`pick_best_range`) to choose the best.
2. Quotes
- Similar line-based pass with `gather_line_quotes(map, caret.row())`.
- If no local quotes found, we do a multi‐line fallback with
`gather_quotes_multiline(map)`, building a big string for the whole
buffer and using naive regex for "...", '...', and `...`.
- Also preserves “inner vs. outer” logic:
- For inner (e.g. `ciq`), we skip bounding quotes or brackets if the
range is at least 2 characters wide.
- For outer (`caq`), we return the entire range.
3. Shared “`finalize`” helpers
- `finalize_bracket_range` and `finalize_quote_range` handle the “inner”
skip‐chars vs. “outer” logic.
- Both rely on the same “line first, then full fallback” approach.
### Why This Matters
- **Old Behavior**: If you had multi‐line brackets { ... } or multi‐line
quotes spanning multiple lines, they weren’t found at all, since we only
scanned line by line. That made text objects like ci{ or ciq fail in
multi-line scenarios.
- **New Behavior**: We still do a quick line pass (for user‐friendly
“line priority”), but now if that fails, we do a single‐pass approach
across the entire buffer. This detects multi‐line pairs and maintains
mini.ai’s “cover‐or‐next” picking logic.
### Example Use Cases
- **Curly braces:** e.g., opening { on line 10, closing } on line 15 →
previously missed; now recognized.
- **Multi‐line quotes**: e.g., "'Line 1\nLine 2', no longer missed. We
do gather_quotes_multiline with a naive regex matching across newlines.
### Tests
- Updated and expanded coverage in:
- test_anyquotes_object:
- Includes a multi-line '...' test case.
- E.g. 'first' false\n<caret>string 'second' → ensuring we detect
multi‐line quotes.
- test_anybrackets_object:
- Verifies line‐based priority but also multi‐line bracket detection.
- E.g., an open bracket ( on line 3, close ) on line 5, which used to
fail.
### Limitations / Future Enhancements
- **Escaping**: The current approach for quotes is naive and doesn’t
handle escape sequences (like \") or advanced parser logic. For deeper
correctness, we’ll need more advanced logic, this is also not supported
in the original mini.ai plugin so it is a known issue that won't be
attended for now.
### Important Notes
- Fix for the bug: https://github.com/zed-industries/zed/issues/23889
this PR addresses that bug specifically for the AnyQuotes text object.
Note that the issue still remains in the built-in motions (ci', ci",
ci`).
- Caret Position Differences: The caret position now slightly deviates
from Vim’s default behavior. This is intentional. I aim to closely mimic
the mini.ai plugin. Because these text objects are optional
(configurable via vim.json), this adjusted behavior is considered
acceptable and in my opinion the new behavior is better and it should be
the default in vim. Please review the new tests for details and context.
- Improved Special Cases: I’ve also refined how “false strings” in the
middle and certain curly-bracket scenarios are handled. The test suite
reflects these improvements, resulting in a more seamless coding
experience overall.
### References:
- Mini.AI plugin in nvim: https://github.com/echasnovski/mini.ai
Thank you for reviewing these changes!
Release Notes:
- Improve logic of aq, iq, ab and ib motions to work more like mini.ai
plugin
Closes#9656. Continuation of #9654, but with the addition of backwards
compatibility for the existing captures.
Release Notes:
- Improved Tree-sitter support with added compatibility for standard
injections captures
---------
Co-authored-by: Finn Evers <finn.evers@outlook.de>
Co-Authored-By: Max <max@zed.dev>
Release Notes:
- vim: Added motions `[[`, `[]`, `]]`, `][` for navigating by section,
`[m`, `]m`, `[M`, `]M` for navigating by method, and `[*`, `]*`, `[/`,
`]/` for comments. These currently only work for languages built in to
Zed, as they are powered by new tree-sitter queries.
- vim: Added new text objects: `ic`, `ac` for inside/around classes,
`if`,`af` for functions/methods, and `g c` for comments. These currently
only work for languages built in to Zed, as they are powered by new
tree-sitter queries.
---------
Co-authored-by: Max <max@zed.dev>
Closes#19372
Release Notes:
- Fixed autoclosing quotes when the string is already open.
- Added autoclosing of rust multiline strings
---------
Co-authored-by: Kurt Wolf <kurtwolfbuilds@gmail.com>
This tackles an issue with us exposing unnecessary env variables in
environment which are not actually needed for tasks themselves (and may
have little utility), yet come into the way of ssh remoting.
/cc @ConradIrwin
Release Notes:
- N/A
Closes#18722
- Replace the `@escape` capture name with `@string.escape` for escape
sequences in Go, Python, Regex, Racket, Ruby, and Scheme.
- Rust
- Add syntax highlighting for escape sequences. Close#18722
- Fix the issue where `@punctuation.delimiter` is being overwritten by
`@operator`.
- Add the period (".") to `@punctuation.delimiter`.
Release Notes:
- N/A
This PR fixes an issue where `/` and `!` in Rust doc comments were being
incorrectly highlighted as operators after #17734.
We solve this by removing them from the operators list and using more
scoped queries to highlight them.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
## Todo
* [x] Parse and present new XML output
* [x] Resolve new edits to buffers and anchor ranges
* [x] Surface resolution errors
* [x] Steps fail to resolve because language hasn't loaded yet
* [x] Treat empty `<symbol>` tag as None
* [x] duplicate assists when editing steps
* [x] step footer blocks can appear *below* the following message header
block
## Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Peter <peter@zed.dev>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>