Closes#38168Closes#42414
We were already using `ExitStatusExt::from_raw()` to construct an
`ExitStatus`, but we were passing in the exit code from
alacritty_terminal's `ChildExit` event. This worked fine on Windows
where `from_raw()` expects an exit code, but on Unix, `from_raw()`
([read
more](https://doc.rust-lang.org/std/os/unix/process/trait.ExitStatusExt.html#tymethod.from_raw))
expects a raw wait status from `waitpid()` and not an exit code.
When a child process was killed by a signal (e.g., SIGSEGV),
`ExitStatus::code()` returns `None` since only normal exits have an exit
code. This caused the terminal to hang because we weren't properly
detecting the exit.
One fix would have been to remove the dependency on `ExitStatus`
entirely, but using the raw wait status gives us more information, we
can now detect exit codes, signal terminations, and more.
The actual fix was upstream in `alacritty_terminal` to send the raw wait
status instead of just the exit code.
Currently using forked patch
https://github.com/zed-industries/alacritty/tree/v0.16-child-exit-patch
which is based on v0.25.1.
Upstream PR: https://github.com/alacritty/alacritty/pull/8825
Release Notes:
- Fixed terminal hanging when a child process is killed by a signal
(e.g., SIGSEGV from null pointer dereference).
- **title_bar: Extract platform_title_bar from title_bar**
- **file_finder no longer depends on search and agent_servers no longer
depend on language_models**
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
We might interface with the LSP using URL heres across remotes that have
differing path styles which then breaks every now and then when we have
windows to unix connections. This should helps us fix these occurences
more correctly
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#26866
### Summary
Adds a git graph to Zed, accessible via the `git_graph::Open` action if
a project has an active repository. There's still more to do, but this
is a solid foundation to expand upon. The code structure is in line with
Zed's codebase and shouldn't require architectural changes to add
missing features.
The git graph can be opened via the command palette (`git graph: open`)
or by binding a key to `git_graph::Open`. It's available when the
project has an active git repository.
### Architecture
Similar to the Debugger, the git graph is split between a data layer and
a view/UI layer. When the view layer is rendering, it queries the data
layer for its active state. This setup allows the data layer to lazily
request graph data (only when needed for rendering), abstracts collab
from the view layer, allows most of the data loading to happen on a
background thread, and makes caching easy to implement.
#### Graph Loading
The graph data is loaded in two phases:
1. `Repository::graph_data()` streams commit structure (SHA, parents,
refs) in chunks of 1000 via `git log`
2. `CommitDataReader` lazily fetches full commit details (author,
timestamp, subject) on-demand using a persistent `git cat-file --batch`
process
This two-phase approach makes the initial loading of the graph as fast
as possible, because `git log` takes significantly longer when all the
needed graph data is queried through it. Zed then lazily loads commits
in the user's viewport through `cat-file --batch`. This makes scrolling
to any place in the graph extremely snappy and benefits the
collaborative architecture by only fetching data needed to render the
graph. It also allows Zed to share commit data between different graph
visualizations (e.g., date order vs. topological order).
#### Performance
Tested on both the Zed and LLVM repositories with good performance in
both cases. The two-phase loading approach and lazy fetching keep the UI
responsive even with large commit histories.
#### Testing
I added property testing that builds randomized commit graphs and
verifies that the graph is constructed correctly. This also works as an
integration test and will be expanded in the future to test collab graph
visualization, graph filtering, commit actions, etc.
### New Crate
- `git_graph` (GPL-licensed) — contains UI and graph computation logic
### Not Yet Implemented
- Remote repository support (collab)
- Filtering by branch
- Commit actions (checkout, cherry-pick, etc.)
- Search
- Open commit view for selected commit
- Resizable columns
- Column filtering
#### Reference
<img width="1624" height="976" alt="Screenshot 2025-01-22 at 8 15 39 PM"
src="https://github.com/user-attachments/assets/0f10924a-3964-462f-b320-42d84d02f7bf"
/>
Special thanks to [Alberto Slavica](https://github.com/pyundev) for
submitting #44405, which was a good base to work off of.
Release Notes:
- git: Add initial version of git graph
---------
Co-authored-by: pyundev <pyundev@users.noreply.github.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This PR implements a UI for the side-by-side diff, using blocks to align
the two sides and adding a coherent `SplitEditorElement`.
Release Notes:
- N/A
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Closes#47098
The root cause of this issue is related to how `Poetry` (and the
upstream `pet-poetry` library) handles path hashing. While perhaps it's
an upstream behavior, we can easily fix it on the Zed side.
The related code are
https://github.com/zed-industries/zed/blob/7ce845210d3af82a57a7518e0abe8c167d60cc6a/crates/languages/src/python.rs#L1181-L1211
In my debugging, I found that `worktree_root` takes the form
`/home/user/project`, but `config.workspace_directories` often ends up
as `/home/user/project/`(with a trailing slash). Normally this wouldn't
be an issue, but `Poetry` generates environment names based on the hash
of the absolute path. Since the hashes for `/home/user/project` and
`/home/user/project/` are different, `pet-poetry` fails to find the
environment.
The fix is straightforward: we just need to ensure the trailing `/` is
removed so the hashes match.
Release Notes:
- Fixed poetry environment not discovered on linux
Adds the ability to create a dev container definition from scratch.
Additionally, separates devcontainer logic out into its own crate, since
it was getting sufficiently complex to separate from the
`recent_projects` crate.
A screen recording of the modal experience:
https://github.com/user-attachments/assets/f6cf95e1-eb7b-4ca3-86c7-c1cbc26ca557
Release Notes:
- Added modal to initialize a dev container definition in the project
with `projects: initialize dev container`
- Added podman support for dev container actions with the `use_podman`
setting
- Improved devcontainer error handling
---------
Co-authored-by: Sam Coward <idoru42@gmail.com>
Closes #ISSUE
Moves the settings content definitions into their own crate, so that
they are compiled+cached separately from settings, primarily to avoid
recompiles due to changes in gpui. In that vain many gpui types such as
font weight/features, and `SharedString` were replaced in the content
crate, either with `*Content` types for font/modifier things, or
`String`/`Arc<str>` for `SharedString`. To make the conversions easy a
new trait method in the settings crate named `IntoGpui::into_gpui`
allows for `into()` like conversions to the gpui types in
`from_settings` impls.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
- **copilot: Fix double lease panic when signing out**
- **Extract copilot_chat into a separate crate**
- **Do not use re-exports from copilot**
- **Use new SignIn API**
- **Extract copilot_ui out of copilot**
Closes#7501
Release Notes:
- Fixed Copilot providing suggestions from different Zed windows.
- Copilot edit predictions now support jumping to unresolved
diagnostics.
Release Notes:
- N/A
TL;DR: There was a closed issue 7 hours ago that changed ashpd version,
it needed another bump.
A dependency of gpui called ashpd has a fix in v0.12.1, GPUI has the
0.12 version. After forking zed and patching the gpui source to be mine
with 0.12.1 it was able to use GPUI as a dependency and compile the
project. The error I was getting and the recomendation to do this PR can
be seen in this [closed issue from
ashpd](https://github.com/bilelmoussaoui/ashpd/issues/325).
After changing the dependecy I hit cargo check:
```bash
Finished `dev` profile [unoptimized + debuginfo] target(s) in 4m 24s
```
And cargo run:
```bash
Compiling zed v0.220.0 (/home/user/git/xaviduds/zed/crates/zed)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 9m 44s
Running `target/debug/zed`
```
Zed compiled and opened:
<img width="1920" height="1042" alt="image"
src="https://github.com/user-attachments/assets/8bc524d1-bc4a-43f8-9da4-b02faecca30c"
/>
`ashpd` 0.11 is incompatible with recent zbus/zvariant releases, causing
a compilation error in Linux. Bumping to 0.12 fixes it.
See: https://github.com/bilelmoussaoui/ashpd/issues/323
To reproduce:
```toml
[package]
name = "test-gpui"
version = "0.1.0"
edition = "2021"
[dependencies]
gpui = { git = "https://github.com/zed-industries/zed" }
```
```bash
...
Compiling ashpd v0.11.0
error[E0277]: the trait bound `AppID: Basic` is not satisfied
--> /home/neulus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ashpd-0.11.0/src/documents/mod.rs:391:16
|
391 | self.0.call("Info", &(doc_id.into())).await
| ^^^^ unsatisfied trait bound
|
help: the trait `Basic` is not implemented for `AppID`
--> /home/neulus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ashpd-0.11.0/src/app_id.rs:10:1
|
10 | pub struct AppID(String);
| ^^^^^^^^^^^^^^^^
= help: the following other types implement trait `Basic`:
&B
BusName<'_>
ErrorName<'_>
InterfaceName<'_>
MemberName<'_>
NonZero<i16>
NonZero<i32>
NonZero<i64>
and 35 others
= note: required for `HashMap<AppID, Vec<Permission>>` to implement `zbus::zvariant::Type`
= note: 1 redundant requirement hidden
= note: required for `(file_path::FilePath, HashMap<AppID, Vec<Permission>>)` to implement `zbus::zvariant::Type`
note: required by a bound in `proxy::Proxy::<'a>::call`
--> /home/neulus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ashpd-0.11.0/src/proxy.rs:172:40
|
166 | pub(crate) async fn call<R>(
| ---- required by a bound in this associated function
...
172 | R: for<'de> Deserialize<'de> + Type,
| ^^^^ required by this bound in `Proxy::<'a>::call`
error[E0277]: the trait bound `DocumentID: Basic` is not satisfied
--> /home/neulus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ashpd-0.11.0/src/documents/mod.rs:500:16
|
500 | self.0.call_versioned("GetHostPaths", &(doc_ids,), 5).await
| ^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Basic` is not implemented for `DocumentID`
--> /home/neulus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ashpd-0.11.0/src/app_id.rs:98:1
|
98 | pub struct DocumentID(String);
| ^^^^^^^^^^^^^^^^^^^^^
= help: the following other types implement trait `Basic`:
&B
BusName<'_>
ErrorName<'_>
InterfaceName<'_>
MemberName<'_>
NonZero<i16>
NonZero<i32>
NonZero<i64>
and 35 others
= note: required for `HashMap<DocumentID, file_path::FilePath>` to implement `zbus::zvariant::Type`
note: required by a bound in `proxy::Proxy::<'a>::call_versioned`
--> /home/neulus/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/ashpd-0.11.0/src/proxy.rs:195:40
|
188 | pub(crate) async fn call_versioned<R>(
| -------------- required by a bound in this associated function
...
195 | R: for<'de> Deserialize<'de> + Type,
| ^^^^ required by this bound in `Proxy::<'a>::call_versioned`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `ashpd` (lib) due to 2 previous errors
```
Release Notes:
- N/A
## Motivation
This PR unifies the async execution infrastructure between GPUI and
other components that depend on the `scheduler` crate (such as our cloud
codebase). By having a scheduler that lives independently of GPUI, we
can enable deterministic testing across the entire stack - testing GPUI
applications alongside cloud services with a single, unified scheduler.
## Summary
This PR completes the integration of the `scheduler` crate into GPUI,
unifying async execution and enabling deterministic testing of GPUI
combined with other components that depend on the scheduler crate.
## Key Changes
### Scheduler Integration (Phases 1-5, previously completed)
- `TestDispatcher` now delegates to `TestScheduler` for timing, clock,
RNG, and task scheduling
- `PlatformScheduler` implements the `Scheduler` trait for production
use
- GPUI executors wrap scheduler executors, selecting `TestScheduler` or
`PlatformScheduler` based on environment
- Unified blocking logic via `Scheduler::block()`
### Dead Code Cleanup
- Deleted orphaned `crates/gpui/src/platform/platform_scheduler.rs`
(older incompatible version)
## Intentional Removals
### `spawn_labeled` and `deprioritize` removed
The `TaskLabel` system (`spawn_labeled`, `deprioritize`) was removed
during this integration. It was only used in a few places for test
ordering control.
cc @maxbrunsfeld @as-cii - The new priority-weighted scheduling in
`TestScheduler` provides similar functionality through
`Priority::High/Medium/Low`. If `deprioritize` is important for specific
test scenarios, we could add it back to the scheduler crate. Let me know
if this is blocking anything.
### `start_waiting` / `finish_waiting` debug methods removed
Replaced by `TracingWaker` in `TestScheduler` - run tests with
`PENDING_TRACES=1` to see backtraces of pending futures when parking is
forbidden.
### Realtime Priority removed
The realtime priority feature was unused in the codebase. I'd prefer to
reintroduce it when we have an actual use case, as the implementation
(bounded channel with capacity 1) could potentially block the main
thread. Having a real use case will help us validate the design.
## Testing
- All GPUI tests pass
- All scheduler tests pass
- Clippy clean
## Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ GPUI │
│ ┌──────────────────────┐ ┌────────────────────────────┐ │
│ │ gpui::Background- │ │ gpui::ForegroundExecutor │ │
│ │ Executor │ │ - wraps scheduler:: │ │
│ │ - scheduler: Arc< │ │ ForegroundExecutor │ │
│ │ dyn Scheduler> │ └────────────┬───────────────┘ │
│ └──────────┬───────────┘ │ │
│ │ │ │
│ └──────────┬──────────────────┘ │
│ ▼ │
│ ┌───────────────────────┐ │
│ │ Arc<dyn Scheduler> │ │
│ └───────────┬───────────┘ │
│ ┌──────────────┴──────────────┐ │
│ ▼ ▼ │
│ ┌──────────────────┐ ┌────────────────────┐ │
│ │ PlatformScheduler│ │ TestScheduler │ │
│ │ (production) │ │ (deterministic) │ │
│ └──────────────────┘ └────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: Yara <git@yara.blue>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Hi Zed team thank you for the awesome editor!
I recently stumbled upon a markdown sequence that seems to cause a crash
```md
- [ ] -
\
-
```
*easier to read escape characters below
```rust
let crash_input = "-\t[\t] -\r\\\n-"
println!("{}", crash_input)
```
## how to reproduce
1. copy the markdown above
2. save the file
3. `[shift]` + `[cmd]` + `p` to open the command palette
4. select `markdown: open preview`
5. crash
I've confirmed that the issue is a bug in pulldown-cmark version 12, and
has been resolved in version
[v0.13.0](https://github.com/pulldown-cmark/pulldown-cmark/releases/tag/v0.13.0)
and specifically fixed in
https://github.com/pulldown-cmark/pulldown-cmark/pull/1017
this PR simply bumps the pulldown-cmark version in zed which resolves
the crash on my local machine.
## recording
https://github.com/user-attachments/assets/dc77132f-0d43-40f3-9841-0bf34fe714fb
Release Notes:
- Fixes crash due to markdown parsing via bumping pulldown-cmark
## Context / Related PRs This PR is the third part of the encoding
support improvements, following:
- #44819: Introduced initial legacy encoding support (Shift-JIS, etc.).
- #45243: Fixed UTF-16 saving behavior and improved binary detection.
## Summary
This PR implements a status bar item that displays the character
encoding of the active buffer (e.g., `UTF-8`, `Shift_JIS`). It provides
visibility into the file's encoding and indicates the presence of a Byte
Order Mark (BOM).
## Features
- **Encoding Indicator**: Displays the encoding name in the status bar.
- **BOM Support**: Appends `(BOM)` to the encoding name if a BOM is
detected (e.g., `UTF-8 (BOM)`).
- **Configuration**: The active_encoding_button setting in status_bar
accepts "enabled", "disabled", or "non_utf8". The default is "non_utf8",
which displays the indicator for all encodings except standard UTF-8
(without BOM).
- **Settings UI**: Provides a dropdown menu in the Settings UI to
control this behavior.
- **Documentation**: Updated `configuring-zed.md` and
`visual-customization.md`.
## Implementation Details
- Created `ActiveBufferEncoding` component in
`crates/encoding_selector`.
- The click handler for the button is currently a **no-op**.
Implementing the functionality to reopen files with a specific encoding
has potential implications for real-time collaboration (e.g., syncing
buffer interpretation across peers). Therefore, this PR focuses strictly
on the visualization and configuration aspects to keep the scope simple
and focused.
- Updated schema and default settings to include
`active_encoding_button`.
## Screenshots
<img width="487" height="104" alt="image"
src="https://github.com/user-attachments/assets/041f096d-ac69-4bad-ac53-20cdcb41f733"
/>
<img width="454" height="99" alt="image"
src="https://github.com/user-attachments/assets/ed76daa2-2733-484f-bb1f-4688357c035a"
/>
## Configuration
To hide the button, add the following to `settings.json`:
```json
"status_bar": {
"active_encoding_button": "disabled"
}
```
- **enabled**: Always show the encoding.
- **disabled**: Never show the encoding.
- **non_utf8**: Shows for non-UTF-8 encodings and UTF-8 with BOM. Only
hides for standard UTF-8 (Default).
<img width="1347" height="415" alt="image"
src="https://github.com/user-attachments/assets/7f4f4938-3320-4d21-852c-53ee886d9a44"
/>
## Heuristic Limitations:
The underlying detection logic (implemented in #44819 and #45243)
prioritizes UTF-8 opening performance and does not guarantee perfect
detection for all encodings. We consider this margin of error
acceptable, similar to the behavior seen in VS Code. A future "Reopen
with Encoding" feature would serve as the primary fallback for any
misdetections.
Release Notes:
- Added a status bar item to display the active file's character encoding (e.g. `UTF-16`). This shows for non-utf8 files by default and can be configured with `{"status_bar":{"active_encoding_button":"disabled|enabled|non_utf8"}}`
## Summary
Addresses #16965
This PR adds support for **opening and saving** files with legacy
encodings (non-UTF-8).
Previously, Zed failed to open files encoded in Shift-JIS, EUC-JP, Big5,
etc., displaying a "Could not open file" error screen. This PR
implements automatic encoding detection upon opening and ensures the
original encoding is preserved when saving.
## Implementation Details
1. **Worktree (Loading)**:
* Updated `load_file` to use `chardetng` for automatic encoding
detection.
* Files are decoded to UTF-8 internal strings for editing, while
preserving the detected `Encoding` metadata.
2. **Language / Buffer**:
* Added an `encoding` field to the `Buffer` struct to store the detected
encoding.
3. **Worktree (Saving)**:
* Updated `write_file` to accept the stored encoding.
* **Performance Optimization**:
* **UTF-8 Path**: Uses the existing optimized `fs.save` (streaming
chunks directly from Rope), ensuring no performance regression for the
vast majority of files.
* **Legacy Encoding Path**: Implemented a fallback that converts the
Rope to a contiguous `String/Bytes` in memory, re-encodes it to the
target format (e.g., Shift-JIS), and writes it to disk.
* *Note*: This fallback involves memory allocation, but it is necessary
to support legacy encodings without refactoring the `fs` crate's
streaming interfaces.
## Changes
- `crates/worktree`:
- Add dependencies: `encoding_rs`, `chardetng`.
- Update `load_file` to detect encoding and decode content.
- Update `write_file` to handle re-encoding on save.
- `crates/language`: Add `encoding` field and accessors to `Buffer`.
- `crates/project`: Pass encoding information between Worktree and
Buffer.
- `crates/vim`: Update `:w` command to use the new `write_file`
signature.
## Verification
I validated this manually using a Rust script to generate test files
with various encodings.
**Results:**
* ✅ **Success (Opened & Saved correctly):**
* **Japanese:** `Shift-JIS` (CP932), `EUC-JP`, `ISO-2022-JP`
* **Chinese:** `Big5` (Traditional), `GBK/GB2312` (Simplified)
* **Western/Unicode:** `Windows-1252` (CP1252), `UTF-16LE`, `UTF-16BE`
* ⚠️ **limitations (Detection accuracy):**
* Some specific encodings like `KOI8-R` or generic `Latin1` (ISO-8859-1)
may partially display replacement characters (`?`) depending on the file
content length. This is a known limitation of the heuristic detection
library (`chardetng`) rather than the saving logic.
Release Notes:
- Added support for opening and saving files with legacy encodings
(Shift-JIS, Big5, etc.)
---------
Co-authored-by: CrazyboyQCD <53971641+CrazyboyQCD@users.noreply.github.com>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Since the rule is no longer a `style` lint as of
[mid-August](https://github.com/rust-lang/rust-clippy/pull/15454), the
comment mentioning it not being one is outdated and should be removed.
> [!NOTE]
> I kept the severity at `error` for now to avoid rustling feathers.
> If `warn` is preferred, feel free to change it yourself or ask me to
do it - it's only 1 line of code, after all.
Release Notes:
- N/A
🔜
TODO:
- [x] Add a utility pane to the left and right edges of the workspace
- [x] Add a maximize button to the left and right side of the pane
- [x] Add a new agents pane
- [x] Add a feature flag turning these off
POV: You're working agentically
<img width="354" height="606" alt="Screenshot 2025-12-13 at 11 50 14 PM"
src="https://github.com/user-attachments/assets/ce5469f9-adc2-47f5-a978-a48bf992f5f7"
/>
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Zed <zed@zed.dev>
Closes https://github.com/zed-industries/zed/issues/39056
Leverages a new `await_on_background` API that spawns the future on the
background but blocks the current task, allowing to borrow from the
surrounding scope.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR restructures the commands of the Edit Prediction CLI (now called
`ep`), to support some flows that are important for the training
process:
* generating zeta2 prompt and expected output, without running
predictions
* scoring outputs that are generated by a system other than the
production code (to evaluate the model during training)
To achieve this, we've restructured the CLI commands so that they all
take as input, and produce as output, a consistent, uniform data format:
a set of one or more `Example` structs, expressible either as the
original markdown format, or as a JSON lines. The `Example` struct
starts with the basic fields that are in human-readable eval format, but
contain a number of optional fields that are filled in by different
steps in the processing pipeline (`context`, `predict`, `format-prompt`,
and `score`).
### To do
* [x] Adjust the teacher model output parsing to use the full buffer
contents
* [x] Move udiff to cli
* [x] Align `format-prompt` with Zeta2's production code
* [x] Change score output to assume same provider
* [x] Move pretty reporting to `eval` command
* [x] Store cursor point in addition to cursor offset
* [x] Rename `edit_prediction_cli2` -> `edit_prediction_cli` (nuke the
old one)
Release Notes:
- N/A
---------
Co-authored-by: Oleksiy Syvokon <oleksiy@zed.dev>
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Ben Kunkle <ben@zed.dev>
This PR partially implements a knowledge distillation data pipeline.
`zeta distill` gets a dataset of chronologically ordered commits and
generates synthetic predictions with a teacher model (one-shot Claude
Sonnet).
`zeta distill --batches cache.db` will enable Message Batches API. Under
the first run, this command will collect all LLM requests and upload a
batch of them to Anthropic. On subsequent runs, it will check the batch
status. If ready, it will download the result and put them into the
local cache.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Tracing code is not included in normal release builds
Documents how to use them in our performance docs
Only the maps and cursors are instrumented atm
# Compile times:
current main: fresh release build (cargo clean then build --release)
377.34 secs
current main: fresh debug build (cargo clean then build )
89.31 secs
tracing tracy: fresh release build (cargo clean then build --release)
374.84 secs
tracing tracy: fresh debug build (cargo clean then build )
88.95 secs
tracing tracy: fresh release build with timings (cargo clean then build
--release --features tracing)
375.77 secs
tracing tracy: fresh debug build with timings (cargo clean then build
--features tracing)
90.03 secs
Release Notes:
- N/A
---------
Co-authored-by: localcc <work@localcc.cc>
To do
* [x] Default to no context retrieval. Allow opting in to LSP-based
retrieval via a setting (for users in `zeta2` feature flag)
* [x] Feed this context to models when enabled
* [x] Make the zeta2 context view work well with LSP retrieval
* [x] Add a UI for the setting (for feature-flagged users)
* [x] Ensure Zeta CLI `context` command is usable
---
* [ ] Filter out LSP definitions that are too large / entire files (e.g.
modules)
* [ ] Introduce timeouts
* [ ] Test with other LSPs
* [ ] Figure out hangs
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Fancy regex has a max backtracking limit which defaults to 1,000,000
backtracks. This avoids spinning the CPU forever in the case that a
match is taking a long time (though does mean that some matches may be
missed).
Unfortunately the verison we depended on causes an infinite loop when
the backtracking limit is hit
(https://github.com/fancy-regex/fancy-regex/issues/137), so we got the
worse of both worlds: matches were missed *and* we spun the CPU forever.
Updating fixes this.
Excitingly regex may gain support for lookarounds
(https://github.com/rust-lang/regex/pull/1315), which will make
fancy-regex much less load bearing.
Closes#43821
Release Notes:
- Fix a bug where search regexes with look-around or backreferences
could hang
the CPU. They will now abort after a certain number of match attempts.
Uses the latest version of the SDK + schema crate. A bit painful because
we needed to move to `#[non_exhaustive]` on all of these structs/enums,
but will be much easier going forward.
Also, since we depend on unstable features, I am pinning the version so
we don't accidentally introduce compilation errors from other update
cycles.
Release Notes:
- N/A
With the merging and publishing of
https://github.com/tree-sitter/tree-sitter-bash/pull/311 , we can now go
ahead and update the version of `tree-sitter-bash` that Zed relies on to
the latest version.
Closes#42091
Release Notes:
- Improved grammar for "Shell Script"
This PR adds word/character diff for expanded diff hunks that have both
a deleted and added section, as well as a setting `word_diff_enabled` to
enable/disable word diffs per language.
- `word_diff_enabled`: Defaults to true. Whether or not expanded diff
hunks will show word diff highlights when they're able to.
### Preview
<img width="1502" height="430" alt="image"
src="https://github.com/user-attachments/assets/1a8d5b71-449e-44cd-bc87-d6b65bfca545"
/>
### Architecture
I had three architecture goals I wanted to have when adding word diff
support:
- Caching: We should only calculate word diffs once and save the result.
This is because calculating word diffs can be expensive, and Zed should
always be responsive.
- Don't block the main thread: Word diffs should be computed in the
background to prevent hanging Zed.
- Lazy calculation: We should calculate word diffs for buffers that are
not visible to a user.
To accomplish the three goals, word diffs are computed as a part of
`BufferDiff` diff hunk processing because it happens on a background
thread, is cached until the file is edited, and is only refreshed for
open buffers.
My original implementation calculated word diffs every frame in the
Editor element. This had the benefit of lazy evaluation because it only
calculated visible frames, but it didn't have caching for the
calculations, and the code wasn't organized. Because the hunk
calculations would happen in two separate places instead of just
`BufferDiff`. Finally, it always happened on the main thread because it
was during the `EditorElement` layout phase.
I used Zed's
[`diff_internal`](https://github.com/zed-industries/zed/blob/02b2aa6c50c03d3005bec2effbc9f87161fbb1e8/crates/language/src/text_diff.rs#L230-L267)
as a starting place for word diff calculations because it uses
`Imara_diff` behind the scenes and already has language-specific
support.
#### Future Improvements
In the future, we could add `AST` based word diff highlights, e.g.
https://github.com/zed-industries/zed/pull/43691.
Release Notes:
- git: Show word diff highlight in expanded diff hunks with less than 5
lines.
- git: Add `word_diff_enabled` as a language setting that defaults to
true.
---------
Co-authored-by: David Kleingeld <davidsk@zed.dev>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
This PR adds workflows to be used for CD in extension reposiories in the
`zed-extensions` organization and updates some of the existing ones with
minor improvemts.
Release Notes:
- N/A
We've realized that a lot of the logic within an
`EditPredictionProvider` is not specific to a particular edit prediction
model / service. Rather, it is just the generic state management
required to perform edit predictions at all in Zed. We want to move to a
setup where there's one "built-in" edit prediction provider in Zed,
which can be pointed at different edit prediction models. The only logic
that is different for different models is how we construct the prompt,
send the request, and parse the output.
This PR also changes the behavior of the staff-only `zeta2` feature flag
so that in only gates your *ability* to use Zeta2, but you can still use
your local settings file to choose between different edit prediction
models/services: zeta1, zeta2, and sweep.
This PR also makes zeta1's outcome reporting and prediction-rating
features work with all prediction models, not just zeta1.
To do:
* [x] remove duplicated logic around sending cloud requests between
zeta1 and zeta2
* [x] port the outcome reporting logic from zeta to zeta2.
* [x] get the "rate completions" modal working with all EP models
* [x] display edit prediction diff
* [x] show edit history events
* [x] remove the original `zeta` crate.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Marco Mihai Condrache