Closes https://github.com/zed-industries/zed/issues/37774
Bug in https://github.com/zed-industries/zed/pull/32927
Instead of using trigger characters to clear cached completions items,
now we check if the query is empty to clear it. Turns out Emmet defines
whole [alphanumeric as trigger
characters](279be10872/index.ts (L116))
which causes flickering.
Clear on trigger characters was introduced to get rid of cached
completions like in the case of "Parent.Foo.Bar", where "." is one of
the trigger characters. This works still since "." is not part of
`completion_query_characters` and hence we use it as a boundary while
building the current query. i.e in this case, the query would be empty
after typing ".", clearing cached completions.
Release Notes:
- Fixed issue where completions menu flashed on every keystroke in TSX
files with emmet extension installed.
This can lead to an infinite regress when using a language server that
supports pull diagnostics, since the excerpts for the diagnostics editor
are set based on the project's diagnostics.
Closes#36772
Release Notes:
- Fixed a bug that could cause duplicated diagnostics with some language
servers.
This allows you to write `buffer_snapshot.debug(ranges, value)` and it
will be displayed in the buffer (or multibuffer!) until that callsite
runs again. `ranges` can be any position (`usize`, `Anchor`, etc), any
range, or a slice or vec of those. `value` just needs a `Debug` impl.
These are stored in a mutable global for convenience, and this is only
available in debug builds.
For example, using this to visualize the captures of the brackets
Tree-sitter query:
<img width="1215" height="480" alt="image"
src="https://github.com/user-attachments/assets/c1878fc7-f6b3-4e27-949e-ecf67a7906b9"
/>
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/37621
Improves https://github.com/zed-industries/zed/issues/24623
Adding scrollbars withing Zed's UI currently is rather cumbersome, as it
requires the copying of a lot of code in order for these to work. Wiring
up settings for scrollbar visibilty always has to be done at the call
site and the state has to be saved and maintained by the caller as well.
Similarly, reserving space has to also be handled by the caller.
This PR changes the way scrollbars work in Zed fundamentally by making
use of the new `use_keyed_state` APIs: Instead of saving the state at
the call site, the window now keeps track of the state corresponding to
scrollbars. This enables us to add scrollbars with e.g. one simple call
on divs:
```rust
div()
.vertical_scrollbar(window, cx)
```
will add a scrollbar to the corresponding container. There are some more
improvements regarding tracking of scrollbar visibility settings (which
is now handled by a trait for each setting that supports this) as well
as reserving space.
Additionally, all needed stuff for layouting, catching events and
reserving space is also now managed by the scrollbar component instead.
This drastically reduces the amount of event listeners and makes
layouting of two scrollbars easier.
Furthermore, this paves the way for more improvements to scrollbars,
such as graceful auto-hide. Only downsight here is that we lose some
customizability in a few areas. However, once this lands, we gain the
ability to quickly follow these up without breaking stuff elsewhere.
This also already fixes a few bugs:
- Scrollbars no longer flicker on first render.
- Auto-hide now properly works for all scrollbars.
- If the content size changes, the scrollbar is updated on the same
frame. Both of these happened because we were computing the scrollbar
sizes too early, causing us to use the sizes from the previous frame or
unitialized sizes.
- The project panel no longer jumps if scrolled all the way to the
bottom and the scrollbar actually auto-hides.
Still TODO:
- [x] Fix scrolling in the debugger memory view
- [x] Clean up some more in the scrollbar component and reduce clones
there
- [x] Ensure we don't over-notify the entity the scrollbar is rendered
within
- [x] Make sure auto-hide properly works for all cases
- [x] Check whether we want to implement the scrollbar trait for
`UniformList`s as well
- ~~ [ ] Use for uniformlist where possible~~ Postponed
- [x] Improve layout for cases where we render both scrollbars.
Release Notes:
- N/A
A very primitive attempt, we just key the editor with the locations and
re-use the editor if we open a new buffer with the same initial
locations and title.
Release Notes:
- Added reusing of reference search buffers when applicable
Closes#37980
There seems to be no reason to hard limit this to 1, and we even have
existing UX for this case already:
<img width="1530" height="748" alt="Bildschirmfoto 2025-09-11 um 11 22
57"
src="https://github.com/user-attachments/assets/d6498318-c905-4d3c-90ab-60e4f2bb6c48"
/>
(Notice the different arrows in the gutter area for single lines)
Hence, allowing the value to honor the request from the issue
Release Notes:
- Allowed `0` as a value for the `excerpt_context_lines` setting
Follow up to https://github.com/zed-industries/zed/pull/37824, which
made items be cut-off in the _editor_ instance of the code actions menu.
This PR applies the default UI font size for the code action menu items
only when the origin is the quick actions bar.
Release Notes:
- Fix code actions menu items being cut-off in the editor.
## Context
While looking into: #32051 and #16120 with instruments, I noticed that
`TabSnapshot::to_tab_point` and `TabSnapshot::to_fold_point` are a
common bottleneck between the two issues. This PR takes the first steps
into closing the stated issues by improving the performance of both
those functions.
### Method
`to_tab_point` and `to_fold_point` iterate through each character in
their rows to find tab characters and translate those characters into
their respective transformations. This PR changes this iteration to take
advantage of the tab character bitmap in the `Rope` data structure and
goes directly to each tab character when iterating.
The tab bitmap is now passed from each layer in-between the `Rope` to
the `TabMap`.
### Testing
I added several randomized tests to ensure that the new `to_tab_point`
and `to_fold_point` functions have the same behavior as the old methods
they're replacing. I also added `test_random_chunk_bitmap` on each layer
the tab bitmap is passed up to the `TabMap` to make sure that the bitmap
being passed is transformed correctly between the layers of
`DisplayMap`.
`test_random_chunk_bitmap` was added to these layers:
- buffer
- multi buffer
- custom_highlights
- inlay_map
- fold_map
## Benchmarking
I setup benchmarks with criterion that is runnable via `cargo bench -p
editor --profile=release-fast`. When benchmarking I had my laptop
plugged in and did so from the terminal with a minimal amount of
processes running. I'm also on a m4 max
### Results
#### To Tab Point
Went from completing 6.8M iterations in 5s with an average time of
`736.13 ns` to `683.38 ns` which is a `-7.1875%` improvement
#### To Fold Point
Went from completing 6.8M iterations in 5s with an average time of
`736.55 ns` to `682.40 ns` which is a `-7.1659%` improvement
#### Editor render
Went from having an average render time of `62.561 µs` to `57.216 µs`
which is a `-8.8248%` improvement
#### Build Buffer with one long line
Went from having an average buffer build time of `3.2549 ms` to `3.2635
ms` which is a `+0.2151%` regression within the margin of error
#### Editor with 1000 multi cursor input
Went from having an average edit time of `133.05 ms` to `122.96 ms`
which is a `-7.5776%` improvement
Release Notes:
- N/A
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Closes#19816
Release Notes:
- Improved `ctrl-k` (`editor::CutToEndOfLine`) behavior when used at the
end of lines
- Add option to make `editor::CutToEndOfLine` not gobble newlines.
```json
{
"context": "Editor",
"bindings": { "ctrl-k": ["editor::CutToEndOfLine", { "stop_at_newlines":
true }] }
},
```
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
This setting controls which visible characters are used to render
whitespace when the show_whitespace setting is enabled.
Release Notes:
- Added `whitespace_map` setting to control which visible characters are
used to render whitespace when the `show_whitespace` setting is enabled.
---------
Co-authored-by: Nia Espera <nia@zed.dev>
Whilst looking into adding support for RainbowBrackes, we stumbled upon
this: Whereas for all properties during this blending, we take the value
of `other` if it is set, for the color we actually take `self.color`
instead of `other.color` if `self.color` is at full opacity.
`Hsla::blend` returns the latter color if it is at full opacity, which
seems wrong for this case. Hence, this PR swaps these.
Will not merge before the next release, to ensure that we don't break
something somewhere unexpected.
Release Notes:
- N/A
Release Notes:
- Fixed matching bracket highlighting not highlighting closing brackets
when adjacent to each other
Co-authored-by: Finn Evers <finn@zed.dev>
Closes#21193Closes#14703
Having the ability to navigate directly to the next
symbolHighlight/reference lets you follow the data flow of a variable.
If you highlight the function itself (depending on the LSP), you can
also navigate to all returns.
Note that this is a different feature from navigating to the next match,
as that is not language-context aware. For example, if you have a var
named foo it would also navigate to an unrelated variable fooBar.
Here's how this patch works:
- The editor struct has a background_highlights.
- Collect all highlights with the keys [DocumentHighlightRead,
DocumentHighlightWrite]
- Depending on the direction, move the cursor to the next or previous
highlight relative to the current position.
Release Notes:
- Added `editor::GoToNextDocumentHighlight` and
`editor::GoToPreviousDocumentHighlight` to navigate to the next LSP
document highlight. Useful for navigating to the next usage of a certain
symbol.
When the cursor was sitting on a syntactically insignificant character,
like a `{` or `,`, this function was selecting only that character, when
what the user likely wanted was to select the next larger syntax node.
Those punctuation characters all seemed to be not "named", in
tree-sitter terminology, so I updated the function to walk up the node
tree until it found a node where `is_named()` is true.
Closes#4555
Also, while writing the tests, the output of a failing test with the
wrong thing selected was harder to read than it needed to be.
It used to output a diff of ranges, like this:
<img width="217" height="111" alt="image"
src="https://github.com/user-attachments/assets/00de53a8-8776-47aa-8101-5a5b5bc3fa5e"
/>
I leveraged the existing `generate_marked_text` helper function and
updated the assertion to output a diff of the text with the selection
markers:
<img width="211" height="116" alt="image"
src="https://github.com/user-attachments/assets/53b2b882-2676-4c70-8718-e2e2ba6f254e"
/>
Happy to make that a separate PR, if needed.
Release Notes:
- Fixed Editor select_larger_syntax_node to be smart about punctuation.
These changes introduce a new command to the Diagnostics panel,
`diagnostics: deploy current file`, which allows the user to view the
diagnostics only for the currently opened file.
Here's a screen recording showing these changes in action 🔽
[diagnostics: deploy current
file](https://github.com/user-attachments/assets/b0e87eea-3b3a-4888-95f8-9e21aff8ea97)
Closes#4739
Release Notes:
- Added new `diagnostics: deploy current file` command to view
diagnostics for the currently open file
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This is an implementation of matching like "m i (", as well as "] (" and
"[ (" in `helix_mode` with a few supported objects and a basis for more.
Release Notes:
- Added helix operators for selecting text objects
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Closes#37597
Release Notes:
- N/A
---
## Problem
When using "Tab Switcher: Toggle All", temporary files (untitled buffers
without associated file paths) cannot be searched by their displayed
content. This creates an inconsistent user experience where:
- **UI Display**: Shows dynamic titles based on the first line of
content (up to 40 characters)
- **Search Text**: Only searches for the static text "untitled"
### Example
- A temporary file containing `Hello World` is displayed as "Hello
World" in the tab
- However, searching for "Hello" in Tab Switcher returns no results
- Only searching for "untitled" will find this temporary file
## Root Cause
The issue stems from inconsistent title generation logic between display
and search:
1. **Display Title** (`items.rs:724`): Uses `self.title(cx)` →
`MultiBuffer::title()` → `buffer_content_title()`
- Returns the first line of content (max 40 chars) for temporary files
2. **Search Text** (`items.rs:650-656`): Uses `tab_content_text()`
method
- Returns hardcoded "untitled" for files without paths
## Solution
Modified the `tab_content_text()` method in `crates/editor/src/items.rs`
to use the same logic as the displayed title for consistency:
```rust
fn tab_content_text(&self, detail: usize, cx: &App) -> SharedString {
if let Some(path) = path_for_buffer(&self.buffer, detail, true, cx) {
path.to_string_lossy().to_string().into()
} else {
// Use the same logic as the displayed title for consistency
self.buffer.read(cx).title(cx).to_string().into()
}
}
```
Follow-up of https://github.com/zed-industries/zed/pull/37352
Closes https://github.com/zed-industries/zed/issues/37132
* disabled word completions in the agent panel's editor
* if not disabled, allow to trigger word completions with an action even
if the completions threshold is not reached
Release Notes:
- Fixed word completions appearing in the agent panel's editor and not
appearing when triggered with the action before the completion threshold
is reached
Bug:
<img width="196" height="95" alt="Screenshot 2025-09-06 at 1 21 39 AM"
src="https://github.com/user-attachments/assets/66ec0fc9-961e-4289-bd75-68b24dad485e"
/>
The fold marker we use, `⋯`, isn’t rendered at the same size as the
editor’s font. Notice how the fold marker appears larger than the same
character typed directly in the editor buffer.
<img width="146" height="82" alt="image"
src="https://github.com/user-attachments/assets/a059d221-6b55-4cf9-bc1e-898ff5444006"
/>
When we shape the line, we use the editor’s font size, and it ends up
determining the element’s width. To fix this, we should treat the
ellipsis as a UI element rather than a buffer character, since current
visual size looks good to me.
<img width="196" height="95" alt="Screenshot 2025-09-06 at 1 29 28 AM"
src="https://github.com/user-attachments/assets/1b766d46-00ab-40c7-b98a-95ea2d4b29bf"
/>
Release Notes:
- Fixed an issue where the fold placeholder’s hover area was smaller
than the marker.
This commit updates the implementation for
`editor::Editor.manipulate_text` to use
`editor::selections_collection::SelectionsCollection.all_adjusted`
instead of `editor::selections_collection::SelectionsCollection.all`, as
the former takes into account the selection's `line_mode`, fixing the
issue where, if an user was in vim's visual line mode, running the
`editor: convert to upper case` command would not work as expected.
Closes#36953
Release Notes:
- Fixed bug where using the editor's convert case commands while in
vim's Visual Line mode would not work as expected
This PR improves the settings_ui proc macro by taking into account more
serde attributes
1. rename_all
2. rename
3. flatten
We also pass field documentation to the UI layer now too. This allows ui
elements to have more information like the switch field description.
We got the scrollbar working and started getting language settings to
show up.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
This PR separates out the associated constant `KEY` from the `Settings`
trait into a new trait `SettingsKey`. This allows for the key trait to
be derived using attributes to specify the path so that the new
`SettingsUi` derive macro can use the same attributes to determine top
level settings paths thereby removing the need to duplicate the path in
both `Settings::KEY` and `#[settings_ui(path = "...")]`
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Extracts and cleans up GPUI's scheduler code into a new `scheduler`
crate, making it pluggable by external runtimes. This will enable
deterministic integration testing with cloud components by providing a
unified test scheduler across Zed and backend code. In Zed, it will
replace the existing GPUI scheduler for consistent async task management
across platforms.
## Changes
- **Core Implementation**: `TestScheduler` with seed-based
randomization, session tracking (`SessionId`), and foreground/background
task separation for reproducible testing.
- **Executors**: `ForegroundExecutor` (!Send, thread-local) and
`BackgroundExecutor` (Send, with blocking/timeout support) as
GPUI-compatible wrappers.
- **Clock and Timer**: Controllable `TestClock` and future-based `Timer`
for time-sensitive tests.
- **Testing APIs**: `once()`, `with_seed()`, and `many()` methods for
configurable test runs.
- **Dependencies**: Added `async-task`, `chrono`, `futures`, etc., with
updates to `Cargo.toml` and lock file.
## Benefits
- **Integration Testing**: Facilitates reliable async tests involving
cloud sessions, reducing flakiness via deterministic execution.
- **Pluggability**: Trait-based design (`Scheduler`) allows easy
integration into non-GPUI runtimes while maintaining GPUI compatibility.
- **Cleanup**: Refactors GPUI scheduler logic for clarity, correctness
(no `unwrap()`, proper error handling), and extensibility.
Follows Rust guidelines; run `./script/clippy` for verification.
- [x] Define and test a core scheduler that we think can power our cloud
code and GPUI
- [ ] Replace GPUI's scheduler
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This PR cleans up some emitted events around the codebase. These events
are either never emitted or never listened for.
It seems better to re-implement these at some point should they again be
needed - this ensures that they will actually be fired in the cases
where they are needed as opposed to being there and getting unreliable
and stale (which is already the case for the majority of the events
removed here).
Lastly, this ensures the `CapabilitiesChanged` event is not fired too
often.
Release Notes:
- N/A
This reverts commit 40199266b6.
The issue with the commit is: ContentMask<Pixels>::intersect is doing
intersection of corner radii which makes inner containers use the max
corner radius out of all the parents when it should be more complex to
correctly clip children (clip sorting..?)
Release Notes:
- N/A
We don’t know the background color behind a non-opaque editor, so we
should skip contrast correction in that case. This prevents
single-editor mode (which is always transparent) from showing weird text
colors when text is selected.
We can’t account for the actual background during contrast correction
because we compute contrast outside gpui, while the actual color
blending happens inside gpui during drawing.
<img width="522" height="145" alt="image"
src="https://github.com/user-attachments/assets/6ee71475-f666-482d-87e6-15cf4c4fceef"
/>
Release Notes:
- Fixed an issue where Command Palette text looked faded when selected.
Closes https://github.com/zed-industries/zed/issues/37144
Adjusts `editor::DeleteToPreviousWordStart`,
`editor::DeleteToNextWordEnd`, `editor::DeleteToNextSubwordEnd` and
`editor::DeleteToPreviousSubwordStart` actions to
* take whitespace sequences with length >= 2 into account and stop after
removing them (whilst movement would also include the word after such
sequences)
* take current language's brackets into account and stop after removing
the text before them
The latter is configurable and can be disabled with `"ignore_brackets":
true` parameter in the action.
Release Notes:
- Improved word deletions to consider whitespace sequences and brackets
by default
Follow up to https://github.com/zed-industries/zed/pull/30598
This PR introduces the `display_options` field in the
`CompletionResponse`, allowing a code context menu width to be
dynamically dictated based on its larger item. This will allow us to
have the @-mentions and slash commands completion menus in the agent
panel not be bigger than it needs to be. It may also be relevant/useful
in the future for other use cases.
For now, we set all instances of code context menus to use a fixed
width, as defined in the PR linked above, which means this PR shouldn't
cause any visual change.
Release Notes:
- N/A
Co-authored-by: Michael Sloan <mgsloan+github@gmail.com>
Closes#37249
We no longer show edit prediction when composing IME since it isn't
useful for unfinished alphabet.
Release Notes:
- Fixed edit predictions showing up during partial IME composition.
Closes #ISSUE
This PR includes the necessary work to get `EditorSettings` showing up
in the settings UI. Including making the `path` field on
`SettingsUiItem`'s optional so that top level items such as
`EditorSettings` which have `Settings::KEY = None` (i.e. are treated
like `serde(flatten)`) have their paths computed correctly for JSON
reading/updating.
It includes the first examples of a pattern I expect to continue with
the `SettingsUi` work with respect to settings reorganization, that
being adding missing defaults, and adding explicit values (or aliases)
to settings which previously relied on `null` being a value for optional
fields.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Initially, the `SettingsUi` trait was tied to `Settings`, however, given
that the `Settings::FileContent` type (which may be the same as the type
that implements `Settings`) will be the type that more directly maps to
the JSON structure (and therefore have the documentation, correct field
names (or `serde` rename attributes), etc) it makes more sense to have
the deriving of `SettingsUi` occur on the `FileContent` type rather than
the `Settings` type.
In order for this to work a relatively important change had to be made
to the derive macro, that being that it now "unwraps" options into their
inner type, so a field with type `Option<Foo>` where `Foo: SettingsUi`
will treat the field as if it were just `Foo`, expecting there to be a
default set in `default.json`. This imposes some restrictions on what
`Settings::FileContent` can be as seen in 1e19398 where `FileContent`
itself can't be optional without manually implementing `SettingsUi`, as
well as introducing some risk that if the `FileContent` type has
`serde(default)`, the default value will override the default value from
`default.json` in the UI even though it may differ (but it should!).
A future PR should probably replace the other settings with `FileContent
= Option<T>` (all of which currently have `T == bool`) with wrapper
structs and have `KEY = None` so the further niceties
`derive(SettingsUi)` will provide such as path renaming, custom UI, auto
naming and doc comment extraction can be used.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This updates `editor: rewrap` to work within doc comments, based on the
code that extends such comments on newline. I added some tests, and I've
tested it out in JS, C and PHP. (Though PHP depends on
https://github.com/zed-extensions/php/pull/40)
Closes#19794Closes#18221
**Caveat:**
~~This will not rewrap an existing single-line block comment, such as
the one provided in #18221:~~ this will now rewrap as expected
```c
/* we can triangulate any convex polygon by picking a vertex and connecting it to the next two vertices; we first read two vertices, and then, for every subsequent vertex, we can form a triangle by connecting it to the first and previous vertex */
```
However, it will rewrap a similar comment if it is shaped like a doc
comment. In other words, this will rewrap as expected:
```c
/*
* we can triangulate any convex polygon by picking a vertex and connecting it to the next two vertices; we first read two vertices, and then, for every subsequent vertex, we can form a triangle by connecting it to the first and previous vertex
*/
```
This seems like a reasonable improvement and limitation to me,
especially as a first step.
cc @smitbarmase because I think that you've been making a lot of the
`newline` and `rewrap` changes recently. (Thank you for those, by the
way!)
Release Notes:
- Added support for rewrap in block comments.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
