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>
I have git installed via [scoop](https://scoop.sh). The current
implementation finds `git.exe` in scoop's shims folder and then tries to
find `bash.exe` relative to it.
For example, `git.exe` (shim) is located at:
```
C:\Users\<username>\scoop\shims\git.exe
```
And the code tries to find `bash.exe` at:
```
C:\Users\<username>\scoop\shims\..\bin\bash.exe
```
which doesn't exist.
This PR changes the logic to first check if `bash.exe` is available in
PATH (using `which::which`), and only falls back to the git-relative
path if that fails.
The fix for this is emitting a wake-up event to tell the terminal to
recalculate its search highlights on resize.
Release Notes:
- terminal: Fix bug where search match highlights wouldn't update their
position when resizing the terminal.
Clang-Format uses uses a YAML config file format.
Use YAML language by default for `.clang-format` and `_clang-format`
filenames.
([source](https://clang.llvm.org/docs/ClangFormatStyleOptions.html))
Add `#yaml-language-server: $schema` to `.clang-format` example in C
language docs.
Release Notes:
- Added support for identifying. `.clang-format` files as YAML by
default
Most of the features for collab were previously listed in the section
that was written for private calls. Most of this PR is moving that
content over to the channel documentation and adapting it slightly.
Private calls have similar collaboration, so we can just point back to
the channels doc in that section and keep it pretty thin / DRY.
Release Notes:
- N/A
Fixes an issue where the terminal cursor wouldn't always be displayed in
the default `blink: "terminal_controlled"` mode unless the terminal
requested cursor blinking.
Release Notes:
- N/A
Closes#41723
This PR fixes an issue with accepting partial semver completions by
including `.` in the completion query. This makes the editor treat the
entire version string as the query, instead of breaking segment at last
`.` .
This PR also adds a test for sorting semver completions. The actual
sorting fix is handled in the `package-version-server` by having it
provide `sort_text`. More:
https://github.com/zed-industries/package-version-server/pull/10
<img width="600" alt="image"
src="https://github.com/user-attachments/assets/7657912f-c6da-4e05-956b-1c044918304f"
/>
Release Notes:
- Fixed an issue where accepting a completion for a semver version in
package.json would append the suggestion to the existing text instead of
replacing it.
- Improved the sorting of semver completions in package.json so the
latest versions appear at the top.
Oleksiy Syvokon