Refactors our query loading to instead have an enum of supported queries
and load the query files themselves in parallel, where possible.
We will use this to warn extension authors when unsupported queries are
present, as we no longer want to ship those as part of the extension.
It also now enforces one file per supported query - only one extension
currently utilizes this feature and was undocumented previously, so I
decided in favor of removing it here, since this will help with
enforcing extensions to just ship query files we actually support in the
future. The extension has also been migrated so that it does not break
with this effort
Side-effect of this change is that we now load both embedded and
external languages up to at least 10%/5% faster, since the files are now
read in parallel as opposed to sequentially one by one.
Release Notes:
- N/A
Bumps the treesitter version to include
https://github.com/tree-sitter/tree-sitter/pull/5851
Also makes some changes to `cx.spawn_dedicated` to make it work on web:
- remove the blocking `recv` on the main thread
- adds a new variant `TaskState::Rendezvous` to allow this code to
synchronously return a task
`TaskState::Rendezvous` is needed because of how
`spawn_dedicated_thread` works:
- the caller provides a callback that produces a non-`Send` `Future` on
the dedicated thread
- the callback is sent to the dedicated thread, executed, and the
resulting `Task` is sent back to the main thread
- this all happens synchronously, so that `spawn_dedicated_thread`
returns a synchronous `Task`
However, the blocking `recv` on the main thread traps on the main worker
in the browser.
This PR replaces that with a call to `recv_async`, but this requires a
new `Rendezvous` variant on `TaskState` which represents "a task that it
still waiting to receive the underlying handle from the dedicated
thread".
It also enables the `flume/spin` feature on the web, which is needed to
avoid a synchronous lock acquisition in `send` (it's replaced with a
spinlock). Note that `send_async` wouldn't work here because it acquires
the same lock, and it's unnecessary because `send` only blocks when the
channel is full, but it's an unbounded channel.
---
Release Notes:
- N/A or Added/Fixed/Improved ...
Closes#62796. Follow-up to #62110.
# Objective
The range of a diagnostic entry is anchored when it is ingested, so it
follows edits. The ranges in the related information kept on the
diagnostic were the ones the server published. A code action request
carried both and reported the same note at two different lines: the
entry Zed flattened that note into had followed the edit, the related
information had not.
The distance does not correct itself either. When diagnostics are merged
rather than replaced, the existing entries are re-collected from their
anchors while the payload is cloned as it is, so the two positions drift
further apart with every edit that passes.
`mlir-lsp-server` shows what this costs. `MLIRTextFile::getCodeActions`
takes the line number out of `relatedInformation`, and
`getCodeActionForDiagnostic` resolves it against its own current
document, reading that line to copy its indentation before inserting the
`expected-note` check.
## Solution
The related information moves from `Diagnostic` onto
`DiagnosticEntry<T>`, next to the range it belongs with. The locations
of the diagnostic's own file are then in the same coordinate space as
that range: anchors inside the buffer, points in the worktree's store.
`Diagnostic` carries no coordinates again, so nothing that is only
meaningful inside one buffer travels with a payload that outlives it.
Every transition goes through `DiagnosticEntry::map_coordinates`: the
unsaved-edit adjustment and the clipping when diagnostics are ingested,
the anchoring in `DiagnosticSet::new`, and the conversion back to points
in `merge_diagnostic_entries`. Only the diagnostic's own range is
widened when it is empty, since that is for how it is rendered, while
the related locations are reported back as the server framed them.
Locations in another file have nothing here to anchor to and are kept as
published, which is also what `mlir-lsp-server` expects, since it skips
them.
`DiagnosticEntryRef` is left alone. It is what the rendering path
iterates, down to the scrollbar markers that walk every diagnostic of
the buffer on each frame, so nothing there converts or allocates. The
entries are read through `diagnostic_entries_in_range` where the request
is built, and `diagnostics_in_range` is now implemented on top of it.
The field is an `Option`, as an empty `Arc<[_]>` still allocates and
most diagnostics carry no related information.
`data` has the same staleness and cannot be anchored, as it is opaque.
## Commits
The third commit is mechanical: it introduces `DiagnosticEntry::new` and
rewrites the literals at its call sites, so that the last commit holds
only the change of behaviour.
## Testing
Three tests, all failing before this change. The first two are added as
separate commits, so that they can be run against `main`:
- `test_code_actions_related_information_follows_edits` edits above the
note and requests code actions, where the two positions for it used to
disagree.
- `test_code_actions_related_information_drifts_across_merges` edits and
pulls diagnostics twice, where the distance used to be every line
inserted since the diagnostic was published rather than the last edit
alone.
- `test_code_actions_related_information_of_disk_based_diagnostics`
publishes a diagnostic computed against the file on disk while the
buffer holds an unsaved edit, covering the adjustment the two positions
share.
- `cargo test -p project`
- `cargo test -p language -p diagnostics -p editor`
- `cargo fmt --all -- --check`
- `./script/clippy -p project -p language`
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed language servers receiving outdated positions for the related
information of a diagnostic when code actions are requested.
Closes#62560.
Supersedes #62108, which was a subset of this one.
Overlaps #62400, see comments.
# Objective
Zed flattens the `relatedInformation` of a diagnostic into non-primary
entries of the same diagnostic group. Before this change it did not
retain the original related information on the primary diagnostic, so
code action requests were built from the entries intersecting the
requested range, with the primary diagnostic carrying no
`relatedInformation`.
This caused incomplete code actions from servers such as
`mlir-lsp-server`, which generates `expected-note` edits by walking the
related information of an error or warning diagnostic.
## Solution
Keep the related information the server published on the primary
diagnostic when the diagnostic comes in, next to `data`, and pass it
back when building the code action request.
Nothing is removed from `context.diagnostics`: the flattened entries are
still sent as before, so a diagnostic the server published on its own
and that Zed merged into a group as supporting information keeps being
sent with the severity the server gave it. What it does not recover is
that diagnostic's own `relatedInformation`: ingestion keeps only its
severity. Unchanged from `main`.
Reassembling it from the flattened entries instead, which is what the
first revision of this PR did, is neither faithful — ingestion trims
messages and drops entries with an empty message or pointing at another
file — nor cheap: diagnostics are not indexed by group, so every request
would scan all diagnostics of the buffer, once per server, on every
selection change.
One caveat: the stored ranges are the ones the server published rather
than anchors, so they do not follow edits made after the diagnostic
arrived, while the primary's range does. An edit in that window can put
a resolved insertion a few lines off — `mlir-lsp-server` places the
`expected-note` line at the note's own position. `data` has the same
property today. Anchoring them would mean carrying related information
through the anchor conversion, which I would rather do as a follow-up if
you consider it worth it.
The field is not carried over the proto conversion, as LSP requests are
only built by the peer that received the diagnostics from the language
server.
## Testing
New tests for:
- related information sent verbatim, including the cross-file and empty
entries that flattening drops;
- no related information;
- a flattened entry whose primary is outside the requested range;
- a server-published supporting diagnostic;
- two servers on the same buffer.
Verified on the repro from #62560 that `mlir-lsp-server` inserts both
the `expected-error` and the `expected-note` check
([screenshot](https://github.com/zed-industries/zed/issues/62560#issuecomment-5278476460)).
- `cargo test -p project`
- `cargo test -p language -p editor -p diagnostics`
- `cargo fmt --all -- --check`
- `./script/clippy -p project -p language`
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed incomplete code actions from language servers that rely on the
related information of a diagnostic.
# Objective
Closes#62617
Turns out #62617 is just a special trigger point of a more general
issue: replacing a line's contents can silently rewrite the line's
indentation with the auto-indent suggestion.
Consider the following Rust code, where the line has an extra tab,
making its indent 8 spaces instead of the default 4:
```Rust
fn main() {
println!("hello world");
}
```
If we select and replace the line's contents (without the indentation):
```Rust
fn main() {
«println!("hello world");»
}
```
with `let a = 8;`, the result is:
```Rust
fn main() {
let a = 8;
}
```
The extra indent has been stripped.
Tracing this down to `Buffer::edit_internal()` in
`crates/language/src/buffer.rs`, the code decides whether the edited
line needs an indent update via the `first_line_is_new` flag, which ends
up as the `old_row` of an `AutoindentRequestEntry`. One of these checks
is:
cdc537c690/crates/language/src/buffer.rs (L2913-L2918)
When replacing a line's contents, the edit range ends exactly at the end
of the line, so `old_start.column + (range_len as u32) == old_line_end`.
Because the check uses `<`, this case meets none of the these
conditions, `first_line_is_new` stays `true`, and an indent update is
triggered. If the manual indent differs from the suggested indent, it
gets overwritten — exactly as in the example above.
For IME input, composition updates replace the previously marked preedit
text, which sits at the end of the line — the same geometry as a full
line-content replacement. In some environments (observed on KDE Wayland
with fcitx), a single keystroke delivers the preedit update twice, so
the replacement happens on the very first keystroke, which is what
#62617 reports. On other platforms, the replacement may happens once the
composition changes, i.e. on the second keystroke, so it takes at least
two characters to trigger.
## Solution
Simply change the guard from `(old_start.column + (range_len as u32) <
old_line_end` to `(old_start.column + (range_len as u32) <=
old_line_end`.
## Testing
Two new tests are added: `test_ime_composition_keeps_manual_indent`
covers the IME input path, and
`test_replacing_line_content_keeps_manual_indent` covers a plain
line-content replacement.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed manual indentation being lost when replacing a line's contents
or typing with an input method
## Summary
Fixes#56449.
Related to #16965.
Zed’s Git panel and Project Diff build UI diffs from `language::Buffer`
diff bases loaded through the Git backend. Git blob loading previously
converted bytes with `String::from_utf8(...).ok()`, so legacy-encoded
blobs were treated as missing and the whole worktree file appeared newly
added.
This follows the same encoding path used for worktree buffers:
- move shared byte decoding and encoding into `language`
- keep Git blob, revision, and index APIs byte-oriented with `Vec<u8>`
- decode diff bases and index contents in `GitStore`, where
`language::Buffer`s are created
- encode index writes using the open buffer’s encoding and BOM so
partial staging does not rewrite the file as UTF-8
- keep worktree loading and saving on the same shared implementation
Regression coverage includes Windows-1251 decoding/encoding,
UTF-8/UTF-16 BOM preservation, raw Windows-1251 Git blob loading, and a
`BufferDiffSnapshot` assertion that a one-line CP1251 edit produces one
modified-line hunk instead of a full-file rewrite.
This does not run Git `textconv` commands. It fixes the reported
legacy-encoding case without executing repository-configured commands or
modifying working files on disk.
## Testing
- `cargo test -p language file_content::tests --locked`
- `cargo test -p git repository::tests::test_load_revisions --locked`
- `CARGO_INCREMENTAL=0 cargo test -p project
git_store::tests::test_decode_git_text_windows_1251_one_line_change
--locked`
- `CARGO_INCREMENTAL=0 cargo test -p project --test integration
test_restaging_hunk_after_optimistic_unstage --locked`
- `CARGO_INCREMENTAL=0 cargo check -p project --tests --locked`
- `CARGO_INCREMENTAL=0 cargo check -p git_ui --tests --locked`
- `cargo fmt --all --check`
- `git diff --check`
## Suggested .rules additions
- N/A
Release Notes:
- Fixed Git panel and Project Diff rendering for legacy-encoded text
files whose Git blobs are not valid UTF-8.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
# Objective
- Zed can hang (and eventually get force-killed) when opening certain
binary files, because `analyze_byte_content`'s UTF-16 heuristic
misclassifies them as UTF-16LE/BE text.
- Reproduced with a real-world case: a ~92 MB OTBM game map file (the
binary map format used by OpenTibia/Tibia servers), which interleaves
short ASCII strings with small u16 length/type fields. Its byte pattern
(mostly-zero high bytes, very few control characters) passed the
existing check, so Zed read the entire file, decoded it as UTF-16, and
opened it as an editable buffer with tens of millions of characters and
effectively no line breaks — a pathological case for the text
layout/renderer that hangs or crashes the app (most noticeably on
Windows).
## Solution
`is_plausible_utf16_text` in `crates/language/src/file_content.rs`
previously only rejected the UTF-16 hypothesis when too many code units
were control characters (> 2%). That's not sufficient on its own: binary
formats that interleave short ASCII fragments with small numeric fields
can have a very low control-character ratio while still not being real
text — most of their "characters" land on stray symbol/high-byte values
rather than letters, digits, or spaces.
This PR adds a second, independent requirement: at least 30% of the
analyzed code units must be letters, digits, or spaces (the bulk of any
real UTF-16 text sample). Both conditions now have to hold for a byte
sequence to be classified as UTF-16 text — otherwise it falls through to
`ByteContent::Binary`, and file loading is rejected early, as intended
for binary files, instead of decoding the whole file as garbled text.
## Testing
- Added `test_length_prefixed_binary_not_misdetected_as_utf16le` in
`crates/worktree/src/worktree.rs`, using a synthetic byte pattern that
reproduces the same statistical shape as the real file (null high bytes,
low control-character ratio, no word-like low bytes) — asserts it is now
classified `Binary`.
- Verified against the real 92 MB `.otbm` file that triggered the bug
(not committed, since it's user data): before the fix it was classified
`Utf16Le`, after the fix it's classified `Binary`.
- Ran the full existing `analyze_byte_content` /
`is_plausible_utf16_text` test suite (`cargo test -p worktree --lib
tests::`) — all 7 tests pass, including the pre-existing positive
UTF-16LE/UTF-16BE detection tests, so legitimate UTF-16 files are
unaffected.
- Built a full `--release` binary on Windows and confirmed opening the
real file now shows "Binary files are not supported" immediately instead
of hanging.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments — N/A, no unsafe
code
- [x] The content adheres to Zed's UI standards — N/A, no UI change
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable — only
affects classification of the first 1 KB of a file, negligible cost
---
Release Notes:
- Fixed: Zed no longer hangs when opening certain binary files (e.g.
game asset/map formats) that were previously misdetected as UTF-16 text.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Prevent auto-indent from using stale syntax when text changes during a
background parse.
## Solution
Keep auto-indent pending and parsing active until the current parse
completes.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Editor: Fixed auto-indent occasionally using stale syntax after rapid
edits.
Fixes InsertLineAbove (Shift + O) auto-indent handling by deciding
whether to trim the first character or the last character based on
direction. Previously, inserting a line above would auto format the line
the cursor was originally on and not the new line (instead of the
correct behavior which is to do the opposite).
No tests because I couldn't find any Vim-specific auto-indent tests and
this only affects Vim mode. If I'm missing something there LMK and I'll
take a closer look.
Closes#52588.
Release Notes:
- Vim: Fixed auto-indentation for insert above action.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
This adds support for running self-hosted Sweep Next Edit edit
prediction models through Zed's OpenAI-compatible provider. The target
use case is a local deployment based on
[sweepai/sweep-next-edit-1.5B](https://huggingface.co/sweepai/sweep-next-edit-1.5B),
using the rewrite-window prompting approach described in [OSS Next
Edit](https://blog.sweep.dev/posts/oss-next-edit). Personal user testing
shows impressive quality from this small edit prediction model.
This is valuable because it allows more flexibility for Zed users to
self-host state of the art next edit prediction models!
This PR addresses the self-hosted workflow discussed in
https://github.com/zed-industries/zed/discussions/50929.
Note that the self-hosted model path needed more than just a new
dropdown value. Zed has to build the rewrite-window prompt shape the
model expects, map the rewritten window back into anchored edits, and
make `prompt_format: "infer"` work with the filename-style model
identifiers that llama-server local server reports.
The main changes are:
- add a `Sweep` prompt format for OpenAI-compatible edit prediction
providers and route it to a dedicated `SweepPrompt` model path
- build Sweep rewrite-window prompts from the active cursor window,
recent change history, and related file excerpts
- convert rewrite responses back into anchored edits and suppress no-op
rewrites
- add fixed cursor-window extraction used by the Sweep rewrite prompt
path
- recognize `sweep-next-edit` model names during `infer`, including
filename-style identifiers such as
`sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf`
- reject reserved Sweep prompt tokens before sending malformed requests
to a self-hosted server
- update the docs to describe the actual Sweep rewrite-window prompt
format
Local setup used for manual verification:
```sh
llama-server \
--hf-repo sweepai/sweep-next-edit-1.5B \
--hf-file sweep-next-edit-1.5b.q8_0.v2.gguf \
--ctx-size 8192 \
--host 127.0.0.1 \
--port 8080
```
```json
{
"edit_predictions": {
"provider": "open_ai_compatible_api",
"open_ai_compatible_api": {
"api_url": "http://127.0.0.1:8080/v1/completions",
"model": "sweepai_sweep-next-edit-1.5B_sweep-next-edit-1.5b.q8_0.v2.gguf",
"prompt_format": "infer",
"max_output_tokens": 512
}
}
}
```
The request that produced this PR included screenshots of the
OpenAI-compatible provider configuration and the prompt format dropdown
with `Sweep` selected.
Tests added in this branch:
- `test_sweep_prompt_format_routes_to_sweep_prompt_model`
- `test_fixed_line_window_around_cursor_start_middle_and_end`
-
`test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits`
-
`test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite`
-
`test_original_window_for_current_window_uses_latest_pre_edit_snapshot`
-
`test_original_window_for_current_window_returns_none_without_matching_history`
-
`test_recent_change_block_from_event_formats_original_and_updated_sections`
Verification run locally:
- `cargo test -p zed sweep_prompt_format_routes`
- `cargo test -p zed subscribe_uses_stale_provider_config`
- `cargo test -p edit_prediction sweep_prompt`
- `cargo test -p edit_prediction
fixed_line_window_around_cursor_start_middle_and_end`
- `cargo test -p edit_prediction
test_sweep_prompt_request_prediction_diffs_rewritten_window_into_anchored_edits`
- `cargo test -p edit_prediction
test_sweep_prompt_request_prediction_returns_none_for_identical_rewrite`
- `./script/clippy -p zed -p edit_prediction -p settings_content`
Release Notes:
- Added support for self-hosted Sweep Next Edit models in
OpenAI-compatible edit predictions, including the `sweep` prompt format
and `infer` detection for `sweep-next-edit` model names.
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#61410
## Summary
Tree-sitter bracket queries can become incomplete when recovering from
syntax errors. The existing code handled incorrect matches by collecting
the delimiters returned by the query and pairing them again in order.
The query missed the innermost closing parenthesis. The repair therefore
worked on an incomplete sequence, paired the innermost opening
parenthesis with the next available close, and shifted every remaining
pair outward.
## Solution
This change records the syntax-node kinds used by each bracket pattern
and, when a syntax layer contains errors, checks the concrete leaves
inside those error nodes for delimiters missing from the query output.
When the opening and closing kinds are different and the error range
remains balanced, the missing delimiters are included in the existing
reconstruction.
## Testing
Reproduced the issue using the C snippet from #22679 and verified that
each parenthesis is matched with its correctly nested partner.
Also verified that unbalanced code does not cause the recovery logic to
invent a missing bracket pair.
## How to Review
The relevant changes are in `BufferSnapshot::fetch_bracket_ranges` in
`crates/language/src/buffer.rs`.
The important distinction is between the bracket-query output and the
concrete syntax leaves inside an error node. Previously, the repair
could only rearrange delimiters present in the query output. It can now
detect when that output is incomplete, add the missing real delimiters,
and run the existing reconstruction over the complete set.
## Self-Review Checklist
* [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)](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:
* Fixed incorrect bracket matching when syntax-error recovery omitted a
delimiter.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes https://github.com/zed-industries/zed/issues/61524https://github.com/zed-industries/zed/issues/60763 was a bogus issue:
the semantic of root `language_settings` is the **default settings for
all languages**, not a "magic string that gets applied when an `!x`
exclusion is mentioned there".
Thus, reverts https://github.com/zed-industries/zed/pull/60984 and
redoes https://github.com/zed-industries/zed/pull/60000 in a correct
way: more custom settings replace less custom ones, same applies to the
language server settings.
Instead of doing some odd `!x` manipulations, the right fix is to remove
the old state as
```diff
impl merge_from::MergeFrom for AllLanguageSettingsContent {
fn merge_from(&mut self, other: &Self) {
...
self.defaults.merge_from(&other.defaults);
for language_settings in self.languages.0.values_mut() {
+ let language_servers = language_settings.language_servers.take();
language_settings.merge_from(&other.defaults);
+ language_settings.language_servers = language_servers;
}
for (language_name, user_language_settings) in &other.languages.0 {
if let Some(existing) = self.languages.0.get_mut(language_name) {
existing.merge_from(&user_language_settings);
} else {
let mut new_settings = self.defaults.clone();
+ new_settings.language_servers = None;
new_settings.merge_from(&user_language_settings);
```
After the final override is determined, `...` is expanded and `!x`
entries are removed from the final list.
Project settings override user settings, so it's possible that a certain
language server is disabled by the user and re-enabled in the project:
worktree trust mechanism is supposed to mitigate the security issues.
More tests were added to cover all the cases.
Release Notes:
- Fixed project settings not re-enabling language servers
Closes#56536
## What & why
Running `zed: import vs code settings` more than once kept re-adding the
same file extensions to `file_types`, so `files.associations` entries
grew without bound:
```json
"file_types": { "c": ["*.keymap", "*.keymap", "*.keymap"] }
```
The import merges the VS Code-derived settings into the user's existing
settings, and `file_types` values were `ExtendingVec`s, whose
`merge_from` appends every incoming value unconditionally.
Per review feedback, instead of changing `ExtendingVec`'s merge
semantics (it also backs ssh/wsl connections, `private_files`, etc.),
this adds a new `ExtendingSet` type that actually behaves like a set,
and switches `FileTypeMap`'s file associations to it:
- Backed by an insertion-order-preserving `IndexSet`, so users' pattern
order round-trips through the settings file unchanged (the import
machinery diffs serialized old/new content to produce edits; a sorted
set would reorder existing arrays).
- Merging only accumulates new values, so re-importing an
already-present association is a no-op.
- Since it's a real set, deserialization also collapses duplicates that
earlier imports already wrote into the settings file.
- `ExtendingVec` and all its other users are untouched.
## Testing
- Added a `test_vscode_import` case that re-imports an already-present
`files.associations` entry and asserts the extension isn't duplicated.
It fails before the change and passes after.
- `cargo test -p settings -p settings_content -p language` pass.
- `./script/clippy -p settings -p settings_content -p language -p
recent_projects -p json_schema_store` is clean.
Release Notes:
- Fixed importing VS Code settings repeatedly adding duplicate
`file_types` entries for `files.associations`.
---------
Co-authored-by: Christopher Biscardi <chris@christopherbiscardi.com>
<img width="1728" height="1084" alt="image"
src="https://github.com/user-attachments/assets/a560b10a-6e26-43ff-b830-c528e2dc6798"
/>
Before, each edit in a 50 MB plaintext file would trigger a lot of
anchor calculations (as chunk is 50 lines only) done on main thread +
did extra work when no language grammar or brackets were available.
The PR now moves all anchor calculations into `computed_chunks:
Mutex<HashMap<usize, RowChunk>>,` cache miss.
`TreeSitterData` is wrapped in `Arc` and shared as a part of the
snapshot, hence the need for `Mutex` and internal mutability here.
Trace after the changes:
<img width="1728" height="1084" alt="image"
src="https://github.com/user-attachments/assets/cb258980-8461-4559-b725-aef63c835e60"
/>
Release Notes:
- Improved input performance in large files
---------
Co-authored-by: Finn Evers <finn@zed.dev>
This adds a dedicated `AvailableLanguages` struct in preparation for a
more cabable language matching based on a given language config. No
functional changes, just shuffling some code around for this round.
Also made the LanguageMatcher non-cloneable in favor of wrapping it in
an Arc, since cloning is rather expensive for this and having a
reference is sufficient in all cases right now.
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
## Context
JSON rainbow bracket colors could shift across row chunk boundaries when
large ancestor objects were omitted by the bounded tree-sitter bracket
query window. This fixes the chunk-local depth reset by caching bracket
chunk data together with the active bracket stack after each chunk, then
using that inherited stack when later chunks are computed. For JSON
object braces that are too large for the bounded query, the
implementation recovers active ancestor `{...}` pairs from the syntax
tree so sibling object braces keep the same color even when jumping
directly to a later chunk.
Closes#50185
## How to Review
`crates/language/src/buffer/row_chunk.rs` adds indexed access to row
chunks so bracket cache computation can walk from the nearest cached
chunk up to the requested chunk.
`crates/language/src/buffer.rs` changes bracket range caching from
storing only per-chunk matches to storing per-chunk matches plus the
active bracket stack after that chunk. It preserves the existing bounded
query and greedy-match repair behavior, while adding JSON-specific
ancestor recovery for large object braces omitted by
`MAX_BYTES_TO_QUERY`.
`crates/language/src/buffer_tests.rs` adds a JSON regression fixture
that exceeds `MAX_BYTES_TO_QUERY`, fetches a later chunk before earlier
chunks, and verifies all same-depth sibling object braces keep the same
`color_index` across row chunks.
Video of manual test below :
[Screencast from 2026-07-10
08-09-30.webm](https://github.com/user-attachments/assets/fca6425b-b79c-4097-b4af-148db6aa23d9)
## 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed JSON rainbow bracket colors changing across row chunk
boundaries.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Remove `.unwrap()` calls in iterator/`Option` chains that could panic at
runtime.
## Solution
Use `and_then`/`filter_map` with `.ok()` for fallible downcasts
(`entry_view_state.rs`) and keystroke parsing (`vim/command.rs`); use a
descriptive `expect` in `suggest_autoindents` where the invariant is
intentional (`buffer.rs`).
## Testing
- `cargo test -p language buffer` (69 passed)
- `cargo test -p vim command` (26 passed)
- `cargo test -p agent_ui entry_view` (3 passed)
## Self-Review Checklist:
- [x] I have reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
extends the precedent set by #43703 (thanks @reflectronic) so that
`textDocument/inlayHint`, `textDocument/codeLens`, and
`textDocument/documentSymbol` correctly track multiple dynamic
registrations by id. previously each register call overwrote the slot on
`ServerCapabilities`, and unregister either silently did nothing
(inlayHint, documentSymbol — no match arm) or wiped the entire
capability (codeLens). now each method keeps its own id-keyed map on
`DynamicRegistrations`; the field on `ServerCapabilities` is cleared
only when the last registration is removed.
textDocument-sync notifications (`didChange`/`didSave`/`willSave`) are
deliberately out of scope — their fan-out semantics are ambiguous in the
spec and were flagged on @smitbarmase's earlier exploration in #36876.
verified with `cargo check -p project -p lsp -p editor`, `cargo test -p
project --test integration -- multi_registration` (3/3 passing), and
`cargo fmt -p project`.
closes part of #37838.
Release Notes:
- Improved support for language servers that dynamically register inlay
hints, code lens, or document symbols multiple times.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Closes#59620
## Problem
A language whose name contains a `/`, such as a custom `PL/X` extension
(`lsp_id` → `pl/x`), broke snippets end to end:
- The `snippets: configure snippets` action wrote the file to
`~/.config/zed/snippets/pl/x.json`, i.e. inside a `pl/` subdirectory.
- The snippet scanner reads `snippets/` non-recursively and skips
directories, so that file was never loaded and the snippet could never
be used.
- The completion lookup keyed off the raw `lsp_id` (`pl/x`), which
wouldn't have matched the file-stem key even if the file had been
scanned.
So Zed's own UI created a snippet file it could never read back.
## Fix
Add `LanguageName::snippet_scope_id()` (the `lsp_id` with `/` and `\`
removed) and use it everywhere a language maps to its snippet file name
or lookup key:
- the Configure Snippets writer and its "already configured" label, and
- the two completion lookups in `editor`.
`PL/X` now maps to a flat `plx.json`, as suggested in the issue. The
`editor::InsertSnippet` action is intentionally left unchanged: its
`language` field is documented to be the snippet file name stem, which
is already separator-free.
Note: files created under the old behavior (nested `foo/bar.json`)
aren't migrated; re-running Configure Snippets writes the corrected flat
file.
## Testing
- Added a `language_core` unit test asserting `snippet_scope_id()`
strips `/` and `\` (e.g. `PL/X` → `plx`).
- `cargo test -p language_core` passes.
- `./script/clippy -p language_core -p language` passes.
- Docs Prettier passes.
Release Notes:
- Fixed snippets being unusable for languages whose name contains a `/`
character
Self-Review Checklist:
- [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
Closes#58686
Release Notes:
- Fixed `.editorconfig` re-enabling trailing whitespace removal when Zed
settings disable it.
---------
Co-authored-by: Martin Ye <martin@zed.dev>
## Context
Closes#58571
When editing `settings.json`, typing a new key under `languages`
triggers language-name autocomplete. The same did not work for
`file_types`, even though both keys map language names to configuration.
The root cause: the JSON schema generator uses `replace_subschema` to
inject installed language names as the allowed properties of a named
type. The `languages` field backed by `LanguageToSettingsMap` (a named
newtype) got this treatment; `file_types` was backed by a raw
`HashMap<Arc<str>, ExtendingVec<String>>` with no named type to target.
The fix introduces a `FileTypeMap` newtype parallel to
`LanguageToSettingsMap` and wires it into the same schema-injection
path.
Video of manual test below :
[Screencast from 2026-06-05
00-04-16.webm](https://github.com/user-attachments/assets/5d8afb60-d566-4c99-ad2a-66ebbb47ed2e)
## How to Review
- `crates/settings_content/src/language.rs` : Adds
`FileTypeMap(HashMap<Arc<str>, ExtendingVec<String>>)` with the full set
of derives (`Debug`, `Clone`, `Default`, `PartialEq`, `Serialize`,
`Deserialize`, `JsonSchema`, `MergeFrom`) and an `IntoIterator for
&FileTypeMap` impl so existing call sites
(`all_languages.file_types.iter().flatten()`) continue to work without
changes. Changes the `file_types` field in `AllLanguageSettingsContent`
from the raw HashMap to `Option<FileTypeMap>`.
- `crates/settings/src/settings_store.rs` : In
`configure_schema_generator`, adds a `replace_subschema::<FileTypeMap>`
call mirroring the existing `LanguageToSettingsMap` one: injects
installed language names as the allowed properties, with
`ExtendingVec<String>` (array of glob patterns) as the value schema.
Adds `test_file_types_schema_generation` to verify the injected
properties.
- `crates/settings/src/vscode_import.rs` : Updates `file_types()` to
return `Option<FileTypeMap>` and wraps the constructed map accordingly.
- `crates/language/src/buffer_tests.rs` : Updates the existing custom
`file_types` test setup to extend the inner map of the new `FileTypeMap`
wrapper explicitly, keeping the language crate test build passing after
the type change.
## 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
**Release Notes :**
- Fixed language name autocomplete not working in the `file_types`
setting
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
# Objective
Fixes#59304
Right now inline html tags don't render with any kind of highlighting,
despite the fact that non-inline html tags do get highlighting.
## Solution
Right now zed already has tree-sitter rules that identifies the inline
blocks so we can add a new tree-sitter grammar rule,
```
((html_tag) @injection.content
(#set! injection.language "html")
(#set! injection.combined))
```
that passes these blocks to the html language server.
## Testing
I did some manual testing:
https://github.com/user-attachments/assets/92e5b322-bbc1-48c3-a615-0d32acc2e7d6
And also added a test:
test_markdown_inline_html_highlighting
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- markdown: Fixed inline html block highlighting.
Closes#60424
## Problem
With the repro from #60424, staging the first deletion hunk marked the
second deletion as staged in the UI even though git still had it
unstaged, and clicking the (incorrectly shown) Unstage button inserted a
duplicate copy of the hunk's contents into the git index on every click.
The root cause is ambiguous hunk placement. The committed text contains
repeated `end\n\n` line runs, so the deletion hunks can "slide": more
than one placement produces a minimal diff. The uncommitted diff (HEAD
vs worktree) anchored the remaining deletion at one row while the
unstaged diff (index vs worktree), recomputed after the partial stage,
anchored the same logical deletion at a different row. Everything that
correlates hunks across those two diffs assumes they agree on positions:
- the secondary-status matching in `hunks_intersecting_range_impl` found
no unstaged hunk at the uncommitted hunk's rows and reported it as
staged (`NoSecondaryHunk`);
- the worktree→index projection in `compute_uncommitted_index_edits`
treated the hunk's position as unchanged text and, on unstage, inserted
the hunk's HEAD content at an index position that already contained it,
duplicating it on every request.
## Fix
Upgrade `imara-diff` from 0.1.8 to 0.2.0 and run
`Diff::postprocess_lines` (imara-diff's port of git's xdiff
slider/indent heuristic) after computing hunks in `buffer_diff`. This
canonicalizes the placement of ambiguous hunks based only on their local
content, so diffs of the same buffer against different base texts anchor
the same logical change at the same rows. A bonus is that Zed's hunk
placement now matches `git diff`'s output for such cases (git has used
the indent heuristic by default since 2.11).
As defense in depth, `compute_uncommitted_index_edits` now drops a
pure-insertion index edit whose content is already present at the target
position, so a stale secondary status can no longer duplicate index
content.
The imara-diff 0.2 API removed the `Sink` trait and the top-level
`diff()` function, so the other call sites (`language/text_diff.rs`,
`zeta_prompt/udiff.rs`, `edit_prediction_metrics/reversal.rs`) are
migrated mechanically to `Diff::compute` + `hunks()` with unchanged
behavior (0.2 also renamed `lines_with_terminator` to `lines` and
changed the default `&str` tokenization to include terminators; the
unified-diff builders keep terminator-less tokens via `str::lines()`).
## Testing
- New regression test `test_staging_hunks_with_ambiguous_placement`
replays the exact repro from #60424 (same file contents): stages the
first deletion, asserts the remaining hunks keep their unstaged status
and the index matches exactly, then issues repeated unstage requests for
the unstaged hunk and asserts the index is unchanged. Before the fix
this test showed the second hunk flipping to staged and the index
growing by one copy of the deleted block per unstage request.
- `buffer_diff`, `language`, `zeta_prompt`, `edit_prediction_metrics`,
`multi_buffer`, `git_ui`, `editor`, and the `project` integration suite
pass.
- One test expectation updated: `editor::test_fold_function_bodies`
asserted the old placement of an ambiguous deletion (blank line before
comment); the canonicalized placement (comment before blank line)
matches what `git diff` produces for the same texts.
Release Notes:
- Fixed staging a hunk sometimes marking a different hunk as staged (and
subsequent unstaging corrupting the git index) when the diff contained
repeated lines
([#60424](https://github.com/zed-industries/zed/issues/60424)).
---------
Co-authored-by: Cole Miller <cole@zed.dev>
type `if (true)`, hit enter, nothing indents. same for for/while.
12aa270 commented these out to stop allman braces over-indenting
(#24976). fixed that, broke this. put them back with an optional `@end`
on the `{}` body so braced blocks stop before the brace and braceless
ones indent. same in tsx.
Fixes#60371.
Release Notes:
- Fixed TypeScript and TSX not auto-indenting the body of a braceless
`if`, `for`, or `while`
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This is necessary to remove some `util` dependencies from crates, as
well as better sharing for our projects. This also includes the WIP
AbsPath abstraction as well as some bug fixes from internal tooling.
Release Notes:
- N/A or Added/Fixed/Improved ...
in a plain text file, cursor before a closing bracket, type an opening
one and nothing autocloses. `anything|)` + `[` gives `anything[|)` not
`anything[]|)`. fine in js/css/py.
autoclose checks the language's `autoclose_before` set. every language
sets one, plain text didn't, so a closing bracket ahead of the cursor
killed it. gave it `)]}`.
went `)]}` not the usual `;:.,=}])>` since plain text only has brackets.
`.typ` (Typst) is a separate extension, needs the same fix there.
Fixes#60560.
Release Notes:
- Fixed nested brackets not auto-closing in plain text files
# Objective
Fixes#59979
With hard tabs on, expanding a multi-line snippet only re-indents the
lines that already start with a tab. Anything with no leading whitespace
(closing brackets, mostly) stays at column 0.
## Solution
Block autoindent shifts each line by the first line's delta, but only
when the line's indent kind matches the target kind. A line with no
indentation defaults to `IndentKind::Space`, so under hard tabs it never
matches and gets skipped. An empty indent doesn't really have a kind, so
I let it adopt the target kind before the check. Lines that actually
have space indentation in a tab buffer are still left alone. Normalizing
those felt like a bigger question than this bug, happy to look at it
separately if wanted.
## Testing
New `test_autoindent_block_mode_with_hard_tabs`, same shape as the
snippet in the issue. Fails on main (closing brace stays at column 0),
passes with the fix. `cargo test -p language` and `-p editor` are green,
clippy and fmt too.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed multi-line snippets leaving unindented lines at column 0 when
`hard_tabs` is enabled.
## Summary
When formatting specific ranges (e.g. via Format Selections), trailing
whitespace removal and final newline enforcement currently operate on
the entire file. This PR makes these operations range-aware, so they
only affect lines within the target ranges.
As noted in #16509, users want `remove_trailing_whitespace_on_save` and
`ensure_final_newline_on_save` to suppress jitter by only touching
changed lines. This PR provides the foundational infrastructure for that
— range-based whitespace and newline operations — which a follow-up PR
will wire into the `format_on_save` modifications mode.
## Changes
- Added `remove_trailing_whitespace_in_ranges` and
`ensure_final_newline_in_range` to `Buffer`
- When a `FormattableBuffer` has ranges set, whitespace and newline
operations now use the range-based variants
- `format_ranges_via_lsp` returns `Ok(None)` instead of an error when
the LSP doesn't support range formatting
- Extracted `anchor_ranges_to_row_ranges` helper to deduplicate
conversion logic
<details><summary>Tests (4)</summary>
- `test_trailing_whitespace_in_ranges` — only modified lines have
whitespace removed
- `test_trailing_whitespace_empty_ranges` — empty ranges → no changes
- `test_final_newline_modified_last_line` — newline added when last line
is in range
- `test_final_newline_unmodified_last_line` — newline not added when
last line is outside range
</details>
---
Self-Review Checklist:
- [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 Format Selection to scope trailing whitespace removal and
final newline enforcement to the selected range instead of the entire
file
- Improved handling of LSP servers that do not support range formatting
by gracefully skipping instead of producing an error
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Overhauls Zed's pickers to make them resizable and give them a preview.
Closes#8279
### Background
The most requested Zed feature has the last year has been a [Telescope
like search box](https://github.com/zed-industries/zed/issues/8279)
[discussion](https://github.com/zed-industries/zed/discussions/22581).
To understand why this is so popular we need to understand search can
serve thee goals:
- Navigation: fuzzy search is faster & easier then clicking in a file
tree
- Exploration: example, find a function by a word in its doc comment
- Collecting: example, getting a list of functions to change
The project search which shows results in a multibuffer is the perfect
way to operate on a list of items. Navigation and Exploration need a lot
of context around each result and offer fast navigation between them.
For both of these live searching is also critical.
The `telescope UI` is a picker with a preview to the right or below.
It's offered in various editors and IDE's most famously Neovim (through
the Telescope plugin), IntelliJ (natively), Helix (natively) and of
course VScode (plugins) and it's _many_ forks.
While having a UI like that for text search (our project search) is most
requested the UX pattern is applied widely, from `find_all_references`
to `bookmarks`. It enhances most pickers. Note that we have over 50
different picker modals!
The community has tried to build something like this for Zed:
- https://github.com/zed-industries/zed/pull/44530
- https://github.com/zed-industries/zed/pull/45307
- https://github.com/zed-industries/zed/pull/46478
- https://github.com/zed-industries/zed/pull/43790
These all became huge PR's that we could not merge for various reasons.
This is a really hard feature to integrate in Zed!
This PR got started as https://github.com/zed-industries/zed/pull/46478
and supercedes that.
### Design
- Extend pickers to support an optional preview with minimal changes to
the pickers themselves.
- Make pickers resizable.
- Complement the existing search do not replace it by having both UI's
share the underlying search and allow freely switching between them.
- Allow extending the preview to things other then files.
- Maintain a clean design on all the pickers.
### Heigh level Implementation overview
- Adds an `Option<Preview>` to `Picker`
- Gives `PickerDelegate` a method to communicate a preview to the Picker
- Overhaul the way pickers are drawn to allow for resizing them.
Implemented on the `Shape` and `SizeBouds` structs.
- Adds a high level way to draw the `footer` and `editor` so we do not
need to change much to the pickers.
- Adds a new text finder Picker
- Adds a way to take a running search from project search and hand it to
the text finder Picker and the other way round
- Give the file finder a preview
### Next steps
A more detailed list and how to help out will be added to the tracking
issue for [Pickes with
previews](https://github.com/zed-industries/zed/issues/56037)
- Add more previews to more pickers!
- Enable selectioning multiple items in pickers and performing actions
on those
- Open selected items in a multibuffer
- Add a way to restore the last picker
- Make popovers (picker attached to some menu) resizable as well
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
TODO (will be done post merge)
---
Release Notes:
- Added resizing via dragging to all picker modals.
- Added a preview to the File finder, the preview can be to the right or
below.
- Added a Text finder picker with a preview as alternative project
search UI. The search is shared and allowes switch between UIs while
running.
---------
Co-authored-by: ozacod <47009516+ozacod@users.noreply.github.com>
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
## Context
Sticky scroll was anchoring multiline signatures to the first outline
context row instead of the row containing the symbol name, which could
leave the sticky header showing unhelpful context. This change carries
each outline item’s `selection_range` through the tree-sitter, LSP,
multi-buffer, and editor paths, then uses that range to choose the
sticky header row.
This is intended to improve sticky scroll generically, not only for one
language. It should help wherever symbol data distinguishes the symbol
name from the larger symbol range:
- tree-sitter outlines that provide a distinct `@name` capture
- LSP document symbols whose `selectionRange` is more precise than
`range`
The actual improvement is still language-dependent, because it relies on
the quality of each language’s outline query or language server symbol
metadata.
Closes#55587
Manual video of the test :
[Screencast from 2026-05-10
14-05-46.webm](https://github.com/user-attachments/assets/40f327d3-cab2-4b85-887b-08b541a102bf)
## How to Review
`crates/language/src/outline.rs`, `crates/language/src/buffer.rs`, and
`crates/language/src/buffer_tests.rs`: Adds `selection_range` to
tree-sitter outline items and verifies that multiline signatures can
anchor sticky scroll on the symbol-name row while preserving the
existing displayed outline text.
`crates/project/src/lsp_store/document_symbols.rs`: Threads LSP document
symbol `selection_range` into `OutlineItem`, keeping enriched labels and
highlight ranges intact while preserving the distinction between the
full symbol range and the selected name range.
`crates/multi_buffer/src/multi_buffer.rs`,
`crates/editor/src/document_symbols.rs`, `crates/editor/src/editor.rs`,
`crates/outline/src/outline.rs`, and
`crates/outline_panel/src/outline_panel.rs`: Propagates
`selection_range` through the places that remap outline items between
buffers, multi-buffers, editors, and outline views.
`crates/editor/src/element.rs` and `crates/editor/src/editor_tests.rs`:
Uses `selection_range` when computing sticky header rows and adds a
regression test covering a multiline signature case from the issue.
`crates/language/Cargo.toml` and `Cargo.lock`: Adds `tree-sitter-c` for
the language-level regression test fixture.
## 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed sticky scroll anchoring to unhelpful context rows for multiline
signatures when symbol metadata provides a more precise name range.
I noticed while working on a personal project which derives some logic
from the core Zed stack that I was getting very unexpected results out
of BufferChunks::next when walking through formatted chunks.
The code calculates the mask for the `tabs`, `chars`, and `newlines`
masks incorrectly, making the mask far too large when we are extracting
chunks when chunk_start != 0.
I believe the reason that this isn't a problem in Zed is that the
InlayMap ends up re-masks all the bitmasks before passing things up the
stack, so covers up the problem, preventing it from causing any damage.
It appears this isn't caught in tests because this only happens when
extracting chunks with formatting, during which we offset our retrieval
by next_capture_start, and the current chunks tests don't use
formatting.
I think the fix is sound. The test is maybe not super ideal, but I
wanted to demonstrate the issue in the pull request.
If we process the following text by chunks:
```rust
use std::cmp::Eq;
```
The first chunk is 'use ' with the chars mask being 0b1111. The second
chunk is 'std' with the chars mask being 0b1111111 when it should just
be 0b111.
Self-Review Checklist:
- [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:
- N/A
Co-authored-by: Lukas Wirth <lukas@zed.dev>
This PR changes how base texts are managed by the `buffer_diff` crate,
to enable keeping two diff entities alive that share the same base text
buffer entity. Previously, each diff owned its own base text buffer and
edited it when calling `BufferDiff::set_snapshot`, so the only way to
reuse the same base text between two diffs was to have two independent
buffers for it, which is pretty inefficient.
After this PR, each diff still has a base text buffer, but
`set_snapshot` doesn't edit it. Instead, that responsibility moves into
the caller. For updating the base text buffer, this PR also introduces a
new pair of APIs, `Buffer::snapshot_with_edits` and
`Buffer::fast_forward`, which allow us to move the parsing of the new
base text into the background and then install the new syntax tree
synchronously on the foreground.
The git store uses the low-level APIs `set_snapshot` and `fast_forward`
directly, and manages the head text and index text buffers itself
(garbage-collecting them when they're no longer needed); this enables
adding an `open_staged_diff` API which returns a diff between the
managed index buffer and the managed head buffer (the latter is also
used for the uncommitted diff's base text). Other downstreams don't need
to reuse a base text buffer, and those have been migrated to use the
high-level `set_base_text` API, which now calls `set_snapshot` and
`fast_forward` internally, with a guard to prevent concurrent updates.
Another change worthy of note is that we now always diff the old base
text with the new base text to create `snapshot_with_edits`.
There are also some incidental bug fixes:
- Fixed an issue where a dangling weak unstaged diff could stick around
in the git store forever
- Restored the `IndexMatchesHead` optimization that had become
inoperative in the remote case
- Fixed a crash in the multibuffer due to the handling of
`BufferDiffEvent::LanguageChanged`, which could cause the multibuffer to
have transforms that were inconsistent with the diff base text.
Self-Review Checklist:
- [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
Closes ZED-81P
Release Notes:
- Fixed a rare crash that could occur while using the uncommitted diff.
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Nucleo tracking issue:
https://github.com/zed-industries/zed/issues/55872
This PR switches the outline picker to use `fuzzy_nucleo`.
with that I refactored the outline fuzzy picking to take advantage of
nucleo and its multi-atom query support. The previous implementation had
a lot going on specifically to work around the lack of multiple atoms,
basically taking matters into its own hands to accomplish the same goals
within the constraints it had.
Instead of having two lists of candidates that we have to run the query
against, we just run a single query and take advantage of the fact that
nucleo chooses the matches that are the furtherest towards the end of
the haystack to implement the same ancestor/leaf filtering. It retains
the leaf only matching on single atom queries.
video:
https://github.com/user-attachments/assets/64baa8d7-fd77-452c-86d1-e08561422d85
Self-Review Checklist:
- [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:
- outline: switch to fuzzy_nucleo
Self-Review Checklist:
- [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
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
This test would cause an infinite loop without the fix.
Closes#53298 and #54069
Release Notes:
- Fixed high CPU usage when using Zeta in some cases (thanks
@clupprich!)
Closes [#58343](<https://github.com/zed-industries/zed/issues/58343>)
This crash happened because Helix paste restored selection using the raw
clipboard text length, but buffer edits normalize CRLF line endings to
LF before inserting. When pasting CRLF text at or near EOF, the restored
selection could extend past the normalized snapshot length and panic in
`MutableSelectionsCollection::select_ranges`. The fix normalizes the
text before measuring it for selection restoration and adds regression
coverage for CRLF paste in Helix mode.
Self-Review Checklist:
- [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:
- Fixed a crash that could occur when pasting at the end of a file in
Helix mode
Sets up infra for fixing #46881. Follow-up to the approach discussed in
#36802 (comment).
The initial problem: Go table tests weren't being detected reliably in
larger files. The old approach created one tree-sitter match per table
row, which hit the cursor match limit (64) and caused rows to be
silently dropped.
The suggested fix was to use query repetition to capture all rows in a
single match, then post-process in Rust.
But this hit another problem: some captured rows aren't valid runnables
(e.g., when a struct has multiple string fields and the query can't tell
which one is the test name). Tree-sitter predicates can't validate
subsets of captures within a match, that logic needs to happen in Rust.
This PR adds a `RunnableResolver` trait that lets languages post-process
multi-capture matches. When a query uses `@_run_item` to mark item
boundaries, we split the captures into per-item groups and pass them to
the resolver. The resolver can then:
- Pick which `@run` to use: e.g., compare field names against
`t.Run(tc.name, ...)` to find the right string field.
- Return per-item extras: only the captures that correspond to the
chosen `@run`.
Release Notes:
- N/A
Ref https://vimdoc.sourceforge.net/htmldoc/options.html#ex%3A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] 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
Closes N/A
Release Notes:
- Support `ex:` identifier in vim modelines.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
This fixes no-op on the newline outdent path when the settings tab size
is greater than the current indent size.
Release Notes:
- Fixed pressing Enter on an empty nested Markdown list item when the
tab size is larger than the list indentation.
Self-Review Checklist:
- [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
Closes#49178
The context for this change is covered in #49178. Some language server
adapters are lazily registered; in remote development or collab
sessions, the local client fails to register these adapters, may causing
certain LSP features to function incorrectly. This PR is intended to
address that.
Release Notes:
- N/A
## Context
This fixes incorrect syntax highlighting inside Rust `json!` macros when
a JSON value is an empty string. In the current Rust tree-sitter
injection setup, most macro bodies are reparsed as nested Rust, which
works for macros like `vec!` but breaks down for JSON-shaped `json!({
... })` content. When the nested Rust parse loses sync at `""`, later
values can inherit incorrect highlighting.
Closes#54838
The fix treats `json!` as an exception to the generic nested-Rust macro
injection rule. That keeps the outer Rust layer responsible for
token-level highlighting inside the macro body, which is enough to
correctly color JSON keys, string values, and booleans without
introducing a brittle JSON-specific injection for Rust token trees.
Manual test after the fix below :
[Screencast from 2026-04-29
00-53-01.webm](https://github.com/user-attachments/assets/26453acf-1d72-4a97-9969-3f8e236dc0cd)
## How to Review
- `crates/grammars/src/rust/injections.scm`: Start here. This is the
functional fix. The generic Rust macro injection rule now excludes
`json`, so `json!` and `serde_json::json!` bodies are no longer reparsed
as nested Rust. Existing special cases like `view!`, `html!`, `sql!`,
and regex-related behavior are left unchanged.
- `crates/language/src/syntax_map/syntax_map_tests.rs`: This adds a
regression test covering the reported case. It verifies that an empty
string inside `serde_json::json!({ ... })` does not break subsequent
highlighting, and that the expected string and boolean captures still
appear for the later JSON entries.
## 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
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed incorrect Rust syntax highlighting after empty string values
inside `json!` macros.
