This reduces hangs on windows when we have many tasks queued up on the
main thread that yield a lot.
Release Notes:
- Reduced hangs on windows in some situations
Introducing this little popover here that's aimed at better
communicating what Zed's built-in edit prediction feature is and how
much people can get of it for free by purely just signing in.
<img width="600" height="1914" alt="Screenshot 2025-11-27 at 9 50@2x"
src="https://github.com/user-attachments/assets/a7013292-f662-4cae-9a6f-0e69a4a4fa1d"
/>
Release Notes:
- N/A
- **release_channel: Do not use prerelease channel for build id**
Prerelease channel specifiers always compare as less than to
non-prerelease, which led to 2 auto-update bugs fixed in
https://github.com/zed-industries/zed/pull/43595 and
https://github.com/zed-industries/zed/pull/43611.
We'll use a dot-delimited build specifiers in form:
release-channel.build_number.sha1 instead
- **auto_update: Do not display full build metadata in update
notification**
Release Notes:
- N/A
Sometimes we are unable to receive messages at all from an agent. This
puts on upper bound on the `initialize` call so we can at least give a
message to the user that something is wrong here.
30s might feel like too long, but I wanted to avoid some false positives
in case there was something an agent needed to do at startup. This will
still communicate to the user at some point that something is wrong,
rather than leave them waiting forever with no signal that something is
going wrong.
Release Notes:
- agent: Show an error message to the user if we are unable to
initialize an ACP agent in a reasonable amount of time.
Update the way that both
`search::buffer_search::BufferSearchBar.replace_next` and
`search::buffer_search::BufferSearchBar.replace_all` are registered as
listeners, so that we don't require the replacement editor to be focused
in order for these listeners to be active, only requiring the
replacement mode to be active in the buffer search bar.
This means that, even if the user is focused on the buffer editor, if
the "Replace Next Match" or "Replace All Matches" buttons are clicked,
the replacement will be performed.
Closes#42471
Release Notes:
- Fixed issue with buffer search bar where the replacement buttons
("Replace Next Match" & "Replace All Matches") wouldn't work if search
bar was not focused
Fixes ZED-3P9
We only clamped the end which for a completely wrong input could cause
us to construct a reversed range which will end up underflowing later
on.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Zeta evals now include a character n-gram metric adapted for multi-edit diffs (“delta chrF”). It works as follows:
1. Reconstruct the original, golden (expected), and actual texts from unified diffs.
- "original": the text before any edits
- "golden": the text after applying the expected edits
- "actual": the text after applying the actual edits
2. Compute n-gram count deltas between original→golden and original→actual.
- n-grams are computed as in chrF (max n=6, whitespace ignored).
3. Compare these deltas to assess how well the actual edits match the expected edits.
- As in standard chrF, classify n-grams as true positives, false positives, and false negatives, and report the F-beta score with beta=2.
Release Notes:
- N/A
There are 3 factors:
1. The Preview channel endpoint does not propagate versions with build
identifier (which we oh-so-conveniently store in pre-release field of
semver).
2. Preview build, once fetched, sees it's version *with* build
identifier (as that's baked into the binary).
3. Auto update logic treats versions with pre-release version as less
than versions without pre-release version.
This in turn makes any Preview client see itself as versioned like
0.214.4-123-asdf1234455311, whereas the latest version on the endpoint
is 0.214.4. Thus, the endpoint version is always more recent than the
client version, causing an update loop.
The fix is to ignore build identifier when comparing versions of
non-nightly channels. This should still let us introduce changes to
auto-update behavior in minor releases in the future.
Closes#43584
Release Notes:
- (Preview only): Fixed an update loop with latest Preview update.
CLOSES #39042
This is a reopening of #34985+.
_Original descrioption_:
In Wayland, the client implement key repeat themself. In Zed this is
ultimately handled by the gpui crate by inserting a timer source into
the event loop which repeat itself if the key is still held down [1].
But it seems the processing of the repeated key event happen
synchronously inside the timer source handler, meaning the effective
rate become slightly lower (since the repeated timer is scheduled using
the 1/rate as delay).
I measured the event processing time on my laptop and it's typically
around 3ms, but sometimes spiking at 10ms. At low key repeat rates this
is probably not _very_ noticeable. I see the default in Zed is set to a
(measly) 16/s, but I assume most systems will use something closer to
25, which is a 40ms delay. So ~3ms is around 7.5% of the delay. At
higher rate the discrepancy become worse of course.
I can visible notice the spikes, and doing some crude stopwatch
measurements using gedit as a reference I can reproduce around 5-10%
slower rates in Zed.
IMO this is significant enough to warrant improving, especially since
some people can get quite used the repeat rate and might feel something
being "off" in Zed.
~~The suggested fix simply subtract the processing time from the next
delay timer.~~
[1] https://github.com/olejorgenb/zed/blob/32df726f3b7fa83e7399f6629c59e0a3f3fff125/crates/gpui/src/platform/linux/wayland/client.rs#L1355
Release Notes:
- Improved Wayland (Linux) key repeat rate precision
Adds a `trigger` field to the zeta1/zeta2 prediction requests so that we
can distinguish between editor, diagnostic, and zeta-cli requests.
Release Notes:
- N/A
Many prediction requests end up being rejected early without ever being
set as the current prediction. Before this change, those cases weren’t
reported as rejections because the `request_prediction_with_*` functions
simply returned `Ok(None)`.
With this update, whenever we get a successful response from the
provider, we will return at least the `id`, allowing it to be properly
reported. The request now also includes a “reject reason,” since the
different variants carry distinct implications for prediction quality.
All of these scenarios are now covered by tests. While adding them, I
also found and fixed a bug where some cancelled predictions were
incorrectly being set as the current one.
Release Notes:
- N/A
---------
Co-authored-by: MrSubidubi <dev@bahn.sh>
Update the `fs::RenameOptions` used by
`project::lsp_store::LocalLspStore.deserialize_workspace_edit` in order
to always set `create_parents` to `true`. Doing this ensures that we'll
always create the folders for the new file path provided by the language
server instead of failing to handle the request in case the parent
- Introduce `create_parents` field to `fs::RenameOptions`
- Update `fs::RealFs.rename` to ensure that the `create_parents` option
is respected
Closes#41820
Release Notes:
- Fixed a bug where using language server's file renaming actions could
fail if the parent directory of the new file did not exist
We were using `std::path::Path::strip_prefix` to determine which
repository an absolute path belongs to, which doesn't work when the
paths are Windows-style but the code is running on unix. Replace it with
a platform-agnostic implementation of `strip_prefix`.
Release Notes:
- Fixed git features not working when a Windows host collaborates with a
unix guest
This adds an intial workflow file that can be pulled in to create a bump
commit for an extension version in an extension repository.
Release Notes:
- N/A
Follow-up to https://github.com/zed-industries/zed/pull/39367
Release Notes:
- Fixed a small issue where a scrollbar would sometimes show in the
editor although the content fix exactly on screen.
While logically not really correct, its better than tearing down the
application until we figure out the root cause here
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#28667
Release Notes:
- Fixed git not preserving file mode when committing. Now if an input file is executable it will be preserved when committed with Zed.
---------
Signed-off-by: 11happy <soni5happy@gmail.com>
Signed-off-by: 11happy <bhuminjaysoni@gmail.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Danilo Leal