Closes https://github.com/zed-industries/zed/issues/42753
Consider the following flow: you submit prompt A. Prompt A generates
some edits. You don't click on either "reject" or "keep"; they stay in a
pending state. You then submit prompt B, but before the agent outputs
any response, you click to edit prompt B, thus submitting a
regeneration.
Before this PR, the above flow would make the edits originated from
prompt A to be auto-rejected. This feels very incorrect and can surprise
users when they see that the edits that were pending got rejected. It
feels more correct to only auto-reject changes if you're regenerating
the prompt that directly generated those edits in the first place. Then,
it also feels more correct to assume that if there was a follow-up
prompt after some edits were made, those edits were passively
"accepted".
So, this is what this PR is doing. Consider the following flow to get a
picture of the behavior change:
- You submit prompt A.
- Prompt A generates some edits.
- You don't click on either "reject" or "keep"; they're pending.
- You then submit prompt B, but before the agents outputs anything, you
click to edit prompt B, submitting a regeneration.
- Now, edits from prompt A will be auto-kept.
Release Notes:
- agent: Improved the "reject"/"keep" behavior when regenerating older
prompts by auto-keeping pending edits that don't originate from the
prompt to-be-regenerated.
The `SumTree::append` method is slow when appending large trees to small
trees. The reason is this code here:
f57f4cd360/crates/sum_tree/src/sum_tree.rs (L628-L630)
`append` is called recursively until `self` and `other` have the same
height, effectively making this code `O(log^2 n)` in the number of
leaves of `other` tree in the worst case.
There are no algorithmic reasons why appending large trees must be this
much slower.
This PR proves it by providing implementation of `append` that works in
logarithmic time regardless if `self` is smaller or larger than `other`.
The helper method `append_large` has the symmetric logic to
`push_tree_recursive` but moves the (unlikely) case of merging
underflowing node in a separate helper function to reduce stack usage. I
am a bit unsure about some implementation choices made in
`push_tree_recursive` and would like to discuss some of these later, but
at the moment I didn't change anything there and tried to follow the
same logic in `append_large`.
We might also consider adding `push_front`/`prepend` methods to
`SumTree`.
I did not find a good benchmark that covers this case so I added a new
one to rope benchmarks.
<details>
<summary>cargo bench (compared to current main)</summary>
```
Running benches\rope_benchmark.rs (D:\zed\target\release\deps\rope_benchmark-59c669d2895cd2c4.exe)
Gnuplot not found, using plotters backend
push/4096 time: [195.67 µs 195.75 µs 195.86 µs]
thrpt: [19.944 MiB/s 19.955 MiB/s 19.964 MiB/s]
change:
time: [+0.2162% +0.3040% +0.4057%] (p = 0.00 < 0.05)
thrpt: [-0.4040% -0.3030% -0.2157%]
Change within noise threshold.
Found 14 outliers among 100 measurements (14.00%)
2 (2.00%) low mild
6 (6.00%) high mild
6 (6.00%) high severe
Benchmarking push/65536: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 7.8s, enable flat sampling, or reduce sample count to 50.
push/65536 time: [1.4431 ms 1.4485 ms 1.4546 ms]
thrpt: [42.966 MiB/s 43.147 MiB/s 43.310 MiB/s]
change:
time: [-3.2257% -1.2013% +0.6431%] (p = 0.27 > 0.05)
thrpt: [-0.6390% +1.2159% +3.3332%]
No change in performance detected.
Found 11 outliers among 100 measurements (11.00%)
1 (1.00%) low mild
5 (5.00%) high mild
5 (5.00%) high severe
append/4096 time: [15.107 µs 15.128 µs 15.149 µs]
thrpt: [257.86 MiB/s 258.22 MiB/s 258.58 MiB/s]
change:
time: [+0.9650% +1.5256% +1.9057%] (p = 0.00 < 0.05)
thrpt: [-1.8701% -1.5026% -0.9557%]
Change within noise threshold.
Found 2 outliers among 100 measurements (2.00%)
1 (1.00%) low mild
1 (1.00%) high severe
append/65536 time: [1.2870 µs 1.4496 µs 1.6484 µs]
thrpt: [37.028 GiB/s 42.106 GiB/s 47.425 GiB/s]
change:
time: [-28.699% -16.073% -0.3133%] (p = 0.04 < 0.05)
thrpt: [+0.3142% +19.151% +40.250%]
Change within noise threshold.
Found 17 outliers among 100 measurements (17.00%)
1 (1.00%) high mild
16 (16.00%) high severe
slice/4096 time: [30.580 µs 30.611 µs 30.639 µs]
thrpt: [127.49 MiB/s 127.61 MiB/s 127.74 MiB/s]
change:
time: [-2.2958% -0.9674% -0.1835%] (p = 0.08 > 0.05)
thrpt: [+0.1838% +0.9769% +2.3498%]
No change in performance detected.
slice/65536 time: [614.86 µs 795.04 µs 1.0293 ms]
thrpt: [60.723 MiB/s 78.613 MiB/s 101.65 MiB/s]
change:
time: [-12.714% +7.2092% +30.676%] (p = 0.52 > 0.05)
thrpt: [-23.475% -6.7244% +14.566%]
No change in performance detected.
Found 14 outliers among 100 measurements (14.00%)
14 (14.00%) high severe
bytes_in_range/4096 time: [3.3298 µs 3.3416 µs 3.3563 µs]
thrpt: [1.1366 GiB/s 1.1416 GiB/s 1.1456 GiB/s]
change:
time: [+2.0652% +3.0667% +4.3765%] (p = 0.00 < 0.05)
thrpt: [-4.1930% -2.9754% -2.0234%]
Performance has regressed.
Found 2 outliers among 100 measurements (2.00%)
2 (2.00%) high severe
bytes_in_range/65536 time: [80.640 µs 80.825 µs 81.024 µs]
thrpt: [771.38 MiB/s 773.28 MiB/s 775.05 MiB/s]
change:
time: [-0.6566% +1.0994% +2.9691%] (p = 0.27 > 0.05)
thrpt: [-2.8835% -1.0875% +0.6609%]
No change in performance detected.
Found 10 outliers among 100 measurements (10.00%)
2 (2.00%) high mild
8 (8.00%) high severe
chars/4096 time: [763.17 ns 763.68 ns 764.36 ns]
thrpt: [4.9907 GiB/s 4.9952 GiB/s 4.9985 GiB/s]
change:
time: [-2.1138% -0.7973% +0.1096%] (p = 0.18 > 0.05)
thrpt: [-0.1095% +0.8037% +2.1595%]
No change in performance detected.
Found 10 outliers among 100 measurements (10.00%)
1 (1.00%) low severe
6 (6.00%) low mild
3 (3.00%) high severe
chars/65536 time: [12.479 µs 12.503 µs 12.529 µs]
thrpt: [4.8714 GiB/s 4.8817 GiB/s 4.8910 GiB/s]
change:
time: [-2.4451% -1.0638% +0.6633%] (p = 0.16 > 0.05)
thrpt: [-0.6589% +1.0753% +2.5063%]
No change in performance detected.
Found 11 outliers among 100 measurements (11.00%)
4 (4.00%) high mild
7 (7.00%) high severe
clip_point/4096 time: [63.148 µs 63.182 µs 63.229 µs]
thrpt: [61.779 MiB/s 61.825 MiB/s 61.859 MiB/s]
change:
time: [+1.0107% +2.1329% +4.2849%] (p = 0.02 < 0.05)
thrpt: [-4.1088% -2.0883% -1.0006%]
Performance has regressed.
Found 5 outliers among 100 measurements (5.00%)
4 (4.00%) high mild
1 (1.00%) high severe
Benchmarking clip_point/65536: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 7.8s, enable flat sampling, or reduce sample count to 50.
clip_point/65536 time: [1.2578 ms 1.2593 ms 1.2608 ms]
thrpt: [49.573 MiB/s 49.631 MiB/s 49.690 MiB/s]
change:
time: [+0.4881% +0.8942% +1.3488%] (p = 0.00 < 0.05)
thrpt: [-1.3308% -0.8863% -0.4857%]
Change within noise threshold.
Found 15 outliers among 100 measurements (15.00%)
1 (1.00%) high mild
14 (14.00%) high severe
point_to_offset/4096 time: [16.211 µs 16.235 µs 16.257 µs]
thrpt: [240.28 MiB/s 240.61 MiB/s 240.97 MiB/s]
change:
time: [-1.4913% +0.1685% +2.2662%] (p = 0.89 > 0.05)
thrpt: [-2.2159% -0.1682% +1.5139%]
No change in performance detected.
Found 2 outliers among 100 measurements (2.00%)
1 (1.00%) high mild
1 (1.00%) high severe
point_to_offset/65536 time: [360.06 µs 360.58 µs 361.16 µs]
thrpt: [173.05 MiB/s 173.33 MiB/s 173.58 MiB/s]
change:
time: [+0.0939% +0.8792% +1.8751%] (p = 0.06 > 0.05)
thrpt: [-1.8406% -0.8715% -0.0938%]
No change in performance detected.
Found 10 outliers among 100 measurements (10.00%)
3 (3.00%) high mild
7 (7.00%) high severe
cursor/4096 time: [19.266 µs 19.282 µs 19.302 µs]
thrpt: [202.38 MiB/s 202.58 MiB/s 202.75 MiB/s]
change:
time: [+1.2457% +2.2477% +2.8702%] (p = 0.00 < 0.05)
thrpt: [-2.7901% -2.1983% -1.2304%]
Performance has regressed.
Found 4 outliers among 100 measurements (4.00%)
2 (2.00%) high mild
2 (2.00%) high severe
cursor/65536 time: [467.63 µs 468.36 µs 469.14 µs]
thrpt: [133.22 MiB/s 133.44 MiB/s 133.65 MiB/s]
change:
time: [-0.2019% +1.3419% +2.8915%] (p = 0.10 > 0.05)
thrpt: [-2.8103% -1.3241% +0.2023%]
No change in performance detected.
Found 12 outliers among 100 measurements (12.00%)
3 (3.00%) high mild
9 (9.00%) high severe
append many/small to large
time: [37.419 ms 37.656 ms 37.929 ms]
thrpt: [321.84 MiB/s 324.17 MiB/s 326.22 MiB/s]
change:
time: [+0.8113% +1.7361% +2.6538%] (p = 0.00 < 0.05)
thrpt: [-2.5852% -1.7065% -0.8047%]
Change within noise threshold.
Found 9 outliers among 100 measurements (9.00%)
9 (9.00%) high severe
append many/large to small
time: [51.289 ms 51.437 ms 51.614 ms]
thrpt: [236.50 MiB/s 237.32 MiB/s 238.00 MiB/s]
change:
time: [-87.518% -87.479% -87.438%] (p = 0.00 < 0.05)
thrpt: [+696.08% +698.66% +701.13%]
Performance has improved.
Found 13 outliers among 100 measurements (13.00%)
4 (4.00%) high mild
9 (9.00%) high severe
```
</details>
Release Notes:
- sum_tree: Make SumTree::append run in logarithmic time
Closes#33903
Release Notes:
- Ensured Zed reuses `GITHUB_TOKEN` env variable when querying GitHub
---
Before fixing:
- The `crates-lsp` extension request captured:
```
curl 'https://api.github.com/repos/MathiasPius/crates-lsp/releases' \
-H 'accept: */*' \
-H 'user-agent: Zed/0.212.3 (macos; aarch64)' \
-H 'host: api.github.com' \
```
- `crates-lsp` extension error:
```
Language server crates-lsp:
from extension "Crates LSP" version 0.2.0: status error 403, response: "{\"message\":\"API rate limit exceeded for x.x.x.x. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)\",\"documentation_url\":\"https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting\"}\n"
```
After fixing:
```
export GITHUB_TOKEN=$(gh auth token)
cargo run
```
- The `crates-lsp` extension request captured:
```
curl 'https://api.github.com/repos/MathiasPius/crates-lsp/releases' \
-H 'authorization: Bearer gho_Nt*****************2KXLw2' \
-H 'accept: */*' \
-H 'user-agent: Zed/0.214.0 (macos; aarch64)' \
-H 'host: api.github.com' \
```
The API rate limitation is resolved.
---
This isn't a perfect solution, but it enables users to avoid the noise.
Closes#38433
Document how to register self-hosted GitHub/GitLab/Bitbucket instances
via git_hosting_providers setting so permalinks and issue links resolve.
Release Notes:
- Added documentation on how to register self-hosted
GitHub/GitLab/Bitbucket instances via the `git_hosting_providers`
setting. This ensures permalinks and issue links can be resolved for
these instances.
### Description
The `installing-extensions.md` guide was missing the directory path for
the Windows platform. It currently only lists the paths for macOS and
Linux. This PR adds the correct path for Windows users
(`%LOCALAPPDATA%\zed\extensions`).
Release Notes:
- N/A
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Changes are made to `parse_path_with_position`:
we try to get the canonical, existing parts of
a path, then append the non-existing parts.
Closes#4441
Release Notes:
- Added the possibility to open a non-existing path using `zed` CLI
```
zed path/to/non/existing/file.txt
```
Co-authored-by: Syed Sadiq Ali <sadiqonemail@gmail.com>
This PR makes the thread markdown editable. This refers to the "open
thread as markdown" feature, where you previously could only read. One
benefit of this move is that it makes a bit more obvious that you can
`cmd-s` to save the markdown, allowing you to store the content of a
given thread. You could already do this before, but due to it being
editable now, you see the tab with a dirty indicator, which communicates
that better.
Release Notes:
- agent: Made the thread markdown editable.
This PR improves the edit prediction page particularly by adding
information about pricing and plans, which wasn't at all mentioned here
before, _and_ by including a section with a keybinding example
demonstrating how to always use just `tab` to always accept edit
predictions.
Release Notes:
- N/A
Fixes a panic that was introduced in #42633. Repro steps:
1. Open the inline assistant and mention a file in the prompt
2. Run the inline assistant
3. Remove the mention and insert a different one
4. 💥
This would happen because the mention set still had a reference to the
old editor, because we create a new one in `PromptEditor::unlink`.
Also removes the unused
`crates/agent_ui/src/context_picker/completion_provider.rs` file, which
was not removed by mistake in the previous PR.
Release Notes:
- N/A
This PR adds back the footer with the "Configure" button in the model
selector but only when the seeing it from the Zed agent (or inline
assistant/text threads). I had removed it a while back because seeing
the "Configure" button, which takes you to the agent panel settings
view, when clicking from an external agent didn't make much sense, given
there's nothing model-wise you can configure from Zed (at least yet) for
an external agent.
This also makes the button in the footer a bit nicer by making it full
screen and displaying a keybinding, so that you can easily do the whole
"trigger model selector → go to settings view" all with the keyboard.
<img width="400" height="870" alt="Screenshot 2025-11-21 at 10 38@2x"
src="https://github.com/user-attachments/assets/c14f2acf-b793-4bc1-ac53-8a8a53b219e6"
/>
Release Notes:
- N/A
- In the launch tab of the new session mode, I've switched it to use the
`InputField` component instead given that had all that we needed
already. Allows for removing a good chunk of editor-related code
- Also in the launch tab, added support for keyboard navigation between
all of the elements there (dropdown, inputs, and switch component)
- Added some simple an empty state treatment for the breakpoint column
when there are none set
https://github.com/user-attachments/assets/a441aa8a-360b-4e38-839f-786315a8a235
Release Notes:
- debugger: Made the input elements within the launch tab in the new
session modal keyboard navigable˙.
This PR finally removes the `CheckboxWithLabel` component, which is not
fully needed given the `Checkbox` can take a `label` method. Then, took
advantage of the opportunity to add more methods with regards to label
customization (position, size, and color) in both the `Checkbox` and
`Switch` components.
Release Notes:
- N/A
We now run git pre-commit hooks before we commit. This ensures we don't
run into timeout issues with askpass delegate and report invalid error
to the user.
Closes#43157
Release Notes:
- Fixed long running pre-commit hooks causing committing from Zed to
fail.
Co-authored-by: Cole Miller <cole@zed.dev>
Previously, this was controllable via the undocumented
ZED_WINDOW_DECORATIONS environment variable (added in #13866). Using an
environment variable for this is inconvenient because it requires users
to set that environment variable somehow before starting Zed, such as in
the .desktop file or persistently in their shell. Controlling this via a
Zed setting is more convenient.
This does not modify the design of the titlebar in any way. It only
moves the existing option from an environment variable to a Zed setting.
Fixes#14165
Client-side decorations (default):
<img width="3840" height="2160" alt="image"
src="https://github.com/user-attachments/assets/525feb92-2f60-47d3-b0ca-47c98770fa8c"
/>
Server-side decorations in KDE Plasma:
<img width="3840" height="2160" alt="image"
src="https://github.com/user-attachments/assets/7379c7c8-e5e3-47ba-a3ea-4191fec9434d"
/>
Release Notes:
- Changed option for Wayland server-side decorations from an environment
variable to settings.json field
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
It is optional for Wayland servers to support server-side decorations.
In particular, GNOME chooses to not implement SSD
(https://gitlab.gnome.org/GNOME/mutter/-/issues/217). So, even if the
application requests SSD, it must draw client-side decorations unless
the application receives a response from the server confirming the
request for SSD.
Before, when the user requested SSD for Zed, but the Wayland server did
not support it, there were no server-side decorations (window titlebar)
drawn, but Zed did not draw the window minimize, maximize, and close
buttons either. This fixes Zed so it always draws the window control
buttons if the Wayland server does not support SSD.
Before on GNOME Wayland with SSD requested:
<img width="3840" height="2160" alt="image"
src="https://github.com/user-attachments/assets/68a6d853-623d-401f-8e7f-21d4dea00543"
/>
After on GNOME Wayland with SSD requested:
<img width="3840" height="2160" alt="image"
src="https://github.com/user-attachments/assets/b258ae8b-fe0e-4ba2-a541-ef6f2c38f788"
/>
Release Notes:
- Fixed window control buttons not showing in GNOME Wayland when SSD
requested
Closes:
- #12338
- #40202
1. Adds two new settings which allow customizing the set of regexes used
to identify path hyperlinks in terminal
1. Fixes path hyperlinks for paths containing unicode emoji and
punctuation, for example, `mojo.🔥`
1. Fixes path hyperlinks for Windows verbatim paths, for example,
`\\?\C:\Over\here.rs`.
1. Improves path hyperlink performance, especially for terminals with a
lot of content
1. Replaces existing custom hard-coded default path hyperlink parsing
logic with a set of customizable default regexes
## New settings
(from default.json)
### terminal.path_hyperlink_regexes
Regexes used to identify paths for hyperlink navigation. Supports
optional named capture
groups `path`, `line`, `column`, and `link`. If none of these are
present, the entire match
is the hyperlink target. If `path` is present, it is the hyperlink
target, along with `line`
and `column` if present. `link` may be used to customize what text in
terminal is part of the
hyperlink. If `link` is not present, the text of the entire match is
used. If `line` and
`column` are not present, the default built-in line and column suffix
processing is used
which parses `line:column` and `(line,column)` variants. The default
value handles Python
diagnostics and common path, line, column syntaxes. This can be extended
or replaced to
handle specific scenarios. For example, to enable support for
hyperlinking paths which
contain spaces in rust output,
```
[
"\\s+(-->|:::|at) (?<link>(?<path>.+?))(:$|$)",
"\\s+(Compiling|Checking|Documenting) [^(]+\\((?<link>(?<path>.+))\\)"
],
```
could be used. Processing stops at the first regex with a match, even if
no link is
produced which is the case when the cursor is not over the hyperlinked
text. For best
performance it is recommended to order regexes from most common to least
common. For
readability and documentation, each regex may be an array of strings
which are collected
into one multi-line regex string for use in terminal path hyperlink
detection.
### terminal.path_hyperlink_timeout_ms
Timeout for hover and Cmd-click path hyperlink discovery in
milliseconds. Specifying a
timeout of `0` will disable path hyperlinking in terminal.
## Performance
This PR fixes terminal to only search the hovered line for hyperlinks
and adds a benchmark. Before this fix, hyperlink detection grows
linearly with terminal content, with this fix it is proportional only to
the hovered line. The gains come from replacing
`visible_regex_match_iter`, which searched all visible lines, with code
that only searches the line hovered on (including if the line is
wrapped).
Local benchmark timings (terminal with 500 lines of content):
||main|this PR|Δ|
|-|-|-:|-|
| cargo_hyperlink_benchmark | 1.4 ms | 13 µs | -99.0% |
| rust_hyperlink_benchmark | 1.2 ms | 11 µs | -99.1% |
| ls_hyperlink_benchmark | 1.3 ms | 7 µs | -99.5% |
Release Notes:
- terminal: New settings to allow customizing the set of regexes used to
identify path hyperlinks in terminal
- terminal: Fixed terminal path hyperlinks for paths containing unicode
punctuation and emoji, e.g. mojo.🔥
- terminal: Fixed path hyperlinks for Windows verbatim paths, for
example, `\\?\C:\Over\here.rs`
- terminal: Improved terminal hyperlink performance, especially for
terminals with a lot of content visible
When no predictions are available for the current buffer, we will now
attempt to predict at the closest diagnostic from the cursor location
that wasn't included in the last prediction request. This enables a
commonly desired kind of far-away jump without requiring explicit model
support.
Release Notes:
- N/A
