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>
Current tree sitter configuration for the outline was not working
correctly since the rule required a strict order, firstly
storage_class_specifier then type_qualifier. This resulted in a failure
to recognize types such as "constexpr int", "const double", etc. This PR
proposes a solution with diagnostic capture of type and storage
qualifiers which ensures full context capture and works well with C++.
Before:
<img width="924" height="365" alt="before"
src="https://github.com/user-attachments/assets/d4e0baab-b074-42fc-8a45-46c93d1d352b"
/>
After:
<img width="866" height="367" alt="after"
src="https://github.com/user-attachments/assets/0e69a4d8-fd91-44b3-bc7e-0c9e39b23d2e"
/>
Release Notes:
- Fixed outline configuration for C++ variables with complex specifiers.
Embeddings have neither been used nor maintained in over a year and
there are currently no plans to use these again any time soon. Hence,
remove support for these here to more clearly indicate that these are
actually not used.
Release Notes:
- N/A
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>
Release Notes:
- Added comment language injections for builtin languages. This enables
highlighting of `TODO`s and similar notes with the comment extension
installed.
Signed-off-by: Donnie Adams <donnie@thedadams.com>
An alternative might be to adjust the logic to not nest items when their
ranges are the same, but then clicking them doesn't work properly /
moving the cursor does not change which is selected. This could probably
be made to work with some extra logic there, but it seems overkill.
The downside of fixing it at the query level is that other parts of the
declaration are not inside the item range. This seems to be fine for
single line declarations - the nearest outline item is highlighted.
However, if a part of the declaration is not included in an item range
and is on its own line, then no outline item is highlighted.
Release Notes:
- Outline Panel: Fixed nesting of var and field declarations with
multiple identifiers in Go and C++
C++ before:
<img width="743" height="227" alt="image"
src="https://github.com/user-attachments/assets/af1a1d76-ecdc-4999-ae9c-95591726ccca"
/>
C++ after:
<img width="795" height="250" alt="image"
src="https://github.com/user-attachments/assets/49667ed3-e088-48b3-a9f0-6a119b5e7648"
/>
Go before:
<img width="859" height="306" alt="image"
src="https://github.com/user-attachments/assets/ecc7530a-ca16-4f37-b8d1-60687f178b12"
/>
Go after:
<img width="900" height="334" alt="image"
src="https://github.com/user-attachments/assets/d741cfb0-59e5-4d27-bd6a-f422204dc972"
/>
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
Before this, indentation did not automatically increase after
if/for/while/do/else statements in C++, and only increased after if/for
in C. This led to Zed using last line logic when inserting lines *after*
the indented statement, as well as not indenting the statement itself,
resulting in irregular indentation during typing.
Just adding indentation (similar to C) creates a new problem: now if a
scope is started with a brace on a new line, that brace is indented.
Thus we need to deindent it.
Using else_clause in the indent guide results in the else statement
being indented forward as well, so we need to deindent that too.
Note: the most significant issue for me is the one where indentation
jumps forward when inserting lines after indented lines. Unfortunately,
it appears that fixing that issue requires all of these other changes. I
would have preferred a simpler fix, but I'm not sure if disabling last
line behavior for C/C++ is appropriate as it probably breaks something
else, like cases where the file is incomplete and the statements can't
be parsed properly.
Editing flow before this change:
[Screencast From 2025-07-16
08-31-36.webm](https://github.com/user-attachments/assets/3dea86c5-47bd-47c2-aee8-b0aa613948e6)
Editing flow after this change:
[Screencast From 2025-07-16
08-35-36.webm](https://github.com/user-attachments/assets/7ef23e60-1ee3-49fd-90f9-d53f909ca674)
(note: the "else" snippet is completely breaking the flow here, but I
think that comes from clangd by default? Unfortunately I haven't found a
way to disable it cleanly but that is a separate problem that happens
right now too.)
Release Notes:
- Improve indentation during typing for C/C++ around if/for/while/do
blocks
- 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>
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>
I made a few tree-sitter queries for improving the highlighting of C++.
There is one query that I'm not totally certain about and would
appreciate some feedback on it, the one that concerns attributes.
Many editor only highlight the identifier as a keyword (This is the
behavior implemented in this commit), while others, for example the
tree-sitter plugin for neovim, tags the entire attribute for
highlighting (double brackets included). I don't know which one is
preferable. Here are screenshots of the two versions:
Release Notes:
- Fixed C++ attributes identifiers being wrongly highlighed through the
tag "variable"
- C++ attribute identifiers (nodiscard,deprecated, noreturn, etc.. ) are
now highlighted through the tag "keyword"
- Changed C++ primitives types (void, bool, int, size_t, etc.. ) to no
longer be highlighted with the tag "keyword", they can now be
highlighted by the tag "type.primitive".
- Added a tag "concept" for highlighting C++ concept identifiers. (This
tag name has been chosen to be the same than the one returned by
clangd's semantic tokens)
ozacod