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
Functions like `function* iterateElements() {}` would not show up in the
editor's navigation outline. With this change, they do.
| **Before** | **After**
|-|-|
|<img width="453" height="280" alt="Screenshot 2025-07-13 at 4 58 22 PM"
src="https://github.com/user-attachments/assets/822f0774-bda2-4855-a6dd-80ba82fffaf3"
/>|<img width="564" height="373" alt="Screenshot 2025-07-13 at 4 58
55 PM"
src="https://github.com/user-attachments/assets/f4f6b84f-cd26-49b7-923b-724860eb18ad"
/>|
Note that I decided to use Zed's agent assistance features to do this PR
as a sort of test run. I don't normally code with an AI assistant, but
figured it might be good in this case since I'm unfamiliar with the
codebase. I must say I was fairly impressed. All the changes in this PR
were done by Claude Sonnet 4, though I have done a manual review to
ensure the changes look sane and tested the changes by running the
re-built `zed` binary with a toy project.
Closes#21631
Release Notes:
- Fixed JS/TS outlines to show generator functions.
Closes#33703
`template_string` consists of `template_substitution` and
`string_fragment` chunks. `template_substitution` should not be
considered a string.
```ts
const variable = `this is a string_fragment but ${this.is.template_substitution}`;
```
Release Notes:
- Fixed auto-complete not showing on typing `.` character in template
literal string in JavaScript and TypeScript files.
First of all thank you for such a fast editor!
I realized that the existing support for detecting runnable test cases
for typescript/javascript is not full. Meanwhile I can run most of test
by pressing "run button":
<img width="713" alt="image"
src="https://github.com/user-attachments/assets/e8bb1cb1-f0a5-4eb1-b9a6-7188a9fa47ae"
/>
I can't run dynamic tests:
<img width="703" alt="image"
src="https://github.com/user-attachments/assets/d7eef1bc-e99a-4f05-9d62-ec49b8194959"
/>
I was curious whether I can improve it on my own and created this pr. I
edited schemas and added minor changes in `TaskTemplate` to allow to
replace '%s' with regexp pattern, so it can match test cases:
<img width="772" alt="image"
src="https://github.com/user-attachments/assets/db3a6fe0-ad90-4853-8e98-4215e41dfe88"
/>
Release Notes:
- Allow to run dynamic TypeScript/JavaScript tests
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Closes#27998
Also fixed an issue where jumping back from closing to opening tags
didn't work in javascript due to missing brackets in our tree-sitter
query.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This is the first step of ["Solution proposal for folding multiline
comments with no
indentation"](https://github.com/zed-industries/zed/discussions/31395):
> 1. Add block_comment in the config.toml for the languages javascript,
typescript, tsx. These are simple languages for this feature, and I am
already familiar with them.
The next step will be:
> 2. Modify the function `crease_for_buffer_row` in `DisplaySnapshot` to
handle multiline comments. `editor::fold` and `editor::fold_all` will
handle multiline comments after this change. To my knowledge,
`editor::unfold`, `editor::unfold_all`, and the **unfold** indicator in
the gutter will already work after folding, but there will be no
**fold** indicator.
Release Notes:
- N/A
Follow up for https://github.com/zed-industries/zed/pull/30768
This PR makes JSDoc auto comment on new line lot better by:
- Inserting delimiters regardless of whether previous delimiters have
trailing spaces or not
- When on start tag, auto-indenting both prefix and end tag upon new
line
This makes it correct as per convention out of the box. No need to
manually adjust spaces on every new line.
https://github.com/user-attachments/assets/81b8e05a-fe8a-4459-9e90-c8a3d70a51a2
Release Notes:
- Improved JSDoc auto-commenting on newline which now correctly indents
as per convention.
- 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>
Closes#18581
Now characters for completing query and word characters, which are
responsible for selecting words by double clicking or navigating, are
different. This fixes a bunch of things:
For settings.json, this improves completions to treat the whole string
as a completion query, instead of just the last word. We now added
"space" as a completion query character without it being a word
character.
For keymap.json, this improves selecting part of an action as the ":"
character is only a completion character and not a word character. So,
completions would still trigger on ":" and query capture will treat ":"
as a word, but for actions like selections and navigation, ":" will be
treated as punctuation.
Before:
Unnecessary related suggestions as query is only the last word which is
"d".
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/8199a715-7521-49dd-948b-e6aaed04c488"
/>
Double clicking `ToggleFold` selects the whole action:
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/c7f91a6b-06d5-45b6-9d59-61a1b2deda71"
/>
After:
Now query is "one d" and it shows only matched ones.
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/1455dfbc-9906-42e8-b8aa-b3f551194ca2"
/>
Double clicking `ToggleFold` only selects part of the action, which is
more refined behavior.
<img width="300" alt="image"
src="https://github.com/user-attachments/assets/34b1c3c2-184f-402f-9dc8-73030a8c370f"
/>
Release Notes:
- Improved autocomplete suggestions in `settings.json`, now whole string
is queried instead of just last word of string, which filters out lot of
false positives.
- Improved selection of action in `keymap.json`, where now you can
double click to only select certain part of action, instead of selecting
whole action.
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Reverts zed-industries/zed#25135
This approach was not the best as explained in the response to the
original PR. Likely, the better approach is to create a newer specific
scope for these kinds of variables under the `@variable` prefix so that
themes can control these pseudo-keywords specifically
Closes#4271
Implemented by kicking of a task on the main thread at the end of
`Editor::handle_input` which waits for the buffer to be re-parsed before
checking if JSX tag completion possible based on the recent edits, and
if it is then it spawns a task on the background thread to generate the
edits to be auto-applied to the buffer
Release Notes:
- Added support for auto-closing of JSX tags
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Max Brunsfeld <max@zed.dev>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Peter Tripp <peter@zed.dev>
Closes#19267
Adds highlight field specifically for `constructor` in JS/TS/TSX so that
it can be highlighted as a different color than regular methods
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#24951
We were highlighting both as `@variable.special` however, they are
_techinically_ keywords and other editors (VSCode/WebStorm) seem to
highlight them as keywords as well.
Release Notes:
- N/A
### 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>
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
- Remove "-" from word_character for CSS/JS/TSX/Markdown
- Makes our word-selection behavior consistent across language modes (and consistent with VSCode).
Fixes#16199
## Description
Recently added template string injections do not completely work for
because any time there is an interpolation (`${// some js content}`)
within an element, its closing tag is not highlighted properly:
This PR fixes the issue:
Release Notes:
- Fixed incomplete syntax highlighting for HTML injections inside
JavaScript template tags.
## Note
I'm a beginner with treesitter so I only modified the part for HTML
usecase.
Should the same solution be applied to other injections (`css`, `js`,
etc.)?
This PR adds syntax highlighting support for `css`, `html`, `js`,
`json`, `sql`, `ts`, `yaml` and `yml` in `javascript`, `typescript` and
`tsx` languages where the contents of tagged template literals are now
highlighted.
This does not actually enable language features (like LSP support), it
only does syntax highlighting.
Before this change:
<img width="561" alt="image"
src="https://github.com/user-attachments/assets/74bace1b-5ce1-4b17-8a97-035bba152d9c">
After this change:
<img width="607" alt="image"
src="https://github.com/user-attachments/assets/f227145b-3f4a-4c27-b14f-7143bb19b4cf">
/cc @mrnugget
Release Notes:
- Added syntax highlighting for tagged template literals in
`javascript`, `typescript` and `tsx` languages for `css`, `html`, `js`,
`json`, `sql`, `ts`, `yaml` and `yml`.
([#15984](https://github.com/zed-industries/zed/issues/15984))
Follow-up of
https://github.com/zed-industries/zed/pull/12095#issuecomment-2123230762
reverting back part of https://github.com/zed-industries/zed/pull/11558
that was related to `language.toml` parsing.
Now all extensions that define `prettier_parser_name` in their language
configs, will enable formatting untitled buffers without any extra
language settings like
```json
{
"languages": {
"JSON": {
"prettier": {
"allowed": true,
"parser": "json"
}
}
}
}
```
Release Notes:
- Improved ergonomics of untitled buffer formatting with prettier, no
extra language settings are needed by default.
Add config for tag autoclosing: add following to lsp section of your
settings:
"vscode-html-language-server": {
"settings": {
"html": { "tagAutoclosing": true }
}
}
It also accepts `css`, `js/ts` and `javascript` as options.
Disable HTML language server in JS/TS/TSX files for now. I decided to
disable it for now as it caused excessive edits in these types of files
(as reported by @mariansimecek in
https://github.com/zed-industries/zed/pull/11761#issuecomment-2122038107);
it looks like HTML language server tries to track language ranges (e.g.
whether a particular span is TS/HTML fragment etc) just like we do.
However in plain JS/TSX files it seems like it treats the whole file as
one big chunk of HTML, which is.. not right, to say the least.
No release note, as HTML extension goodies are not on Preview yet.
Release Notes:
- N/A
Fixes#5267
TODO:
- [x] Publish our fork of vscode-langservers-extracted on GH and wire
that through as a language server of choice for HTML extension.
- [x] Figure out how to prevent edits made by remote participants from
moving the cursor of a host.
Release Notes:
- Added support for autoclosing of HTML tags in local projects.
Closes https://github.com/zed-industries/zed/issues/11517
* Removes forced prettier parser name for languages, making `auto`
command to run prettier on every file by default.
* Moves prettier configs away from plugin language declarations into
language settings
Release Notes:
- N/A
Hey guys! `emmet-language-server` author here. Thank you so much for the
amazing editor!
This PR adds more languages to the list for the `emmet-language-server`
to attach to.
I have a question though, I saw that you guys don't differentiate yet
between `JavaScript` and `JSX` files. I know that the tree-sitter parser
for `js` comes with the ability to parse both but we still need to make
that difference. Is that part of the plan? or do you have a reason for
doing that?
Aside from that, I've still added support for `JavaScript` files since
is important to have emmet completions in `JSX` files, but I would like
to know what are your thoughts on that since doing this may pollute the
completions in `.js` files.
And one last thing, the emmet language server accepts more filetypes
such as `pug`, `sass`, `scss` and `less` files, which are not currently
supported by zed. Should I create some extensions to add grammar support
to those files later? Should those extensions be part of the zed repo?
I'm just thinking that those are sort of core languages.
Aside from that, let me know if there's anything left to do on my side.
Greetings!
Fixes#10654.
Release Notes:
- N/A
I saved the `file_types.json` file and got a diff because it had some
trailing whitespace. I ran
[`lineman`](https://github.com/JosephTLyons/lineman) on the codebase.
I've done this before, but this time, I've added in the following
settings to our `.zed` local settings, to make sure every future save
respects our desire to have consistent whitespace formatting.
```json
"remove_trailing_whitespace_on_save": true,
"ensure_final_newline_on_save": true
```
Release Notes:
- N/A
This PR adds the ability for extensions to provide certain language
settings via the language `config.toml`.
These settings are then merged in with the rest of the settings when the
language is loaded from the extension.
The language settings that are available are:
- `tab_size`
- `hard_tabs`
- `soft_wrap`
Additionally, for bundled languages we moved these settings out of the
`settings/default.json` and into their respective `config.toml`s .
For languages currently provided by extensions, we are leaving the
values in the `settings/default.json` temporarily until all released
versions of Zed are able to load these settings from the extension.
---
Along the way we ended up refactoring the `Settings::load` method
slightly, introducing a new `SettingsSources` struct to better convey
where the settings are being loaded from.
This makes it easier to load settings from specific locations/sets of
locations in an explicit way.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
