Closes#47907
Implements the four git checkpoint operations (`create`, `restore`,
`compare`, `diff`) that had been stubbed out for remote repositories,
and related test infrastructure.
Testing steps:
1. Open a project with a `.devcontainer` configuration and connect to
the Dev Container
2. Open an Agent thread and ask the agent to make a code change
3. After the agent completes, verify the "Restore from checkpoint"
button appears (previously missing in Dev Container sessions)
4. Click "Restore from checkpoint" and confirm the file reverts to its
prior state
Release Notes:
- Added support for git checkpoint operations in remote/Dev Container
sessions, restoring the "Restore from checkpoint" button in Agent
threads.
---------
Co-authored-by: KyleBarton <kjb@initialcapacity.io>
Syntax highlighting and its customization are very important to many
developers, including me. I've looked through a number of issues and
discussions on this topic and haven't found any active PRs. Currently,
there's no way to customize highlighting for custom JSX tags, as they
use `@type`. Since TSX has a particularly complex syntax and can often
contain types/aliases/generics/tags in a dense sequence, they all blends
into a single color and makes it difficult to "parse" by eyes.
To avoid proposing something arbitrary, I looked into how this is done
elsewhere.
- VS Code `support.class.component.tsx`
[TypeScriptReact.tmLanguage.json](724656efa2/extensions/typescript-basics/syntaxes/TypeScriptReact.tmLanguage.json (L5802))
But it relies on both legacy [tmLanguage naming
conventions](https://macromates.com/manual/en/language_grammars#:~:text=rarely%20be%20used\).-,support,-%E2%80%94%20things%20provided%20by)
and the outdated assumption that React components are always classes.
- ReScript `@tag`
[rescript-zed](b3930c1754/languages/rescript/highlights.scm (L277))
It's not entirely correct to just use a `@tag` - it's better to
distinguish JSX Intrinsic Elements from custom ones.
- Vue `@tag @tag.component.type.constructor`
[zed-extensions/vue](2697588c5c/languages/vue/highlights.scm (L9C21-L9C52))
- Svelte `@tag @tag.component.type.constructor`
[zed-extensions/svelte](ae381a1217/languages/svelte/highlights.scm (L46C21-L46C52))
The similarity between Vue and Svelte implementations (perhaps one
borrowed from the other) didn't seem coincidental and the approach felt
appropriate.
**I decided to adopt the same one to maintain consistency for theme
creators.**
So, how it looks:
**Release (0.224.9) version**
<img width="440" height="220" alt="zed-one-release"
src="https://github.com/user-attachments/assets/6f8726c5-a17e-4387-941c-69e5c1569049"
/>
**Local version with changes** - no breaking changes for builtin themes
- uses `type` color as before and can be changed in themes separately if
needed
<img width="440" height="220" alt="zed-one-local"
src="https://github.com/user-attachments/assets/a11cc5ed-20fc-45d2-8ebd-a908503999c3"
/>
**Local version with changes and theme overrides**
<img width="440" height="220" alt="zed-one-with-overrides"
src="https://github.com/user-attachments/assets/1997bd5b-7fa4-4346-8338-b5d61e9e832b"
/>
With these changes in the config:
```jsonc
"theme_overrides": {
"One Light": {
"syntax": {
// "tag.component" also matches
"type.component": {
"color": "#d3604fff",
},
},
},
},
```
I'm pretty sure this will help many developers enjoy Zed even more.
Release Notes:
- Improved syntax highlighting for custom jsx elements in TSX and
JavaScript languages. Theme authors and users can now highlight these in
their theme/theme overrides using `tag.component.jsx`
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>
After #52953 gets merged the git graph will be ready for it's preview
release, so we can finally remove the feature flag! AKA this PR releases
the git graph
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- Add Git Graph. Can be accessed through the button on the bottom of the
git panel or the `git graph: Open` action
Update the heading typeface to use IBM Plex Serif, the code typeface to
use Lilex (IBM Plex Mono), and pull them from the zed.dev CDN. Also
added some stray design adjustments here and there.
Release Notes:
- N/A
### Summary
This PR integrates the git graph canvas with the `Table` component’s
`RedistributableColumnsState`, making the graph column resizable while
preserving the table’s existing resize behavior. In particular, column
resizing continues to use the same cascading redistribution behavior as
the table. This is also the last PR needed to remove the feature flag on
the git graph!
### Table API changes
I pulled the redistributable column logic out of `Table` into reusable
UI helpers so layouts outside of `Table` can participate in the same
column resizing behavior. This adds a shared
`RedistributableColumnsState` API, along with helpers for binding
drag/drop behavior, rendering resize handles, and constructing header
resize metadata. I also added `ColumnWidthConfig::explicit` and
`TableRenderContext::for_column_widths` so callers can render table like
headers and content with externally managed column widths.
The reason for this change is that the git graph now renders a custom
split layout: a graph canvas on the left and table content on the right.
By reusing the same column state and resize machinery, the graph column
can resize together with the table columns while preserving the existing
table behavior, including cascading column redistribution and double
click reset to default sizing.
I also adjusted the resize handle interaction styling so the divider
stays in its hovered/highlighted state while a drag is active, which
makes the drag target feel more stable and visually consistent during
resizing.
### Preview
https://github.com/user-attachments/assets/347eed71-0cc1-4db4-9dee-a86ee5ab6f91
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A or Added/Fixed/Improved ...
Now that I've started migrating blog content into the `zeddotdev-images`
bucket, I've added a bit of structure.
`/blog`
`/docs`
This PR just updates the links so we can stay organized going forward.
Shouldn't be seeing much thrash like this after this PR.
Release Notes:
- N/A
This PR mostly moves some code around. It also adds a high-level
`format_expected_output` function that routes patch formatting to
specific prompt formats. This was `zeta_prompt` can format
`expected_output` for training.
Keeping everything prompt-related in a "pure" module (with no heavy
dependencies) makes it easier to write bindings.
Release Notes:
- N/A
## Summary
- PR #48109 changed the capture name for C/C++ preprocessor directives
from `@keyword.directive` to `@preproc`. While semantically correct, the
builtin themes had `preproc` defined with colors nearly
indistinguishable from plain text (e.g. One Dark `#dce0e5ff`, Ayu Dark
`#bfbdb6ff`), making `#include`, `#define`, etc. appear unhighlighted.
- This PR updates the `preproc` color in all builtin themes (and the
fallback theme) to match their respective `keyword` color, restoring
visible highlighting for preprocessor directives.
Fixes#49024
## Side effects
- Go uses `@preproc` for `//go:` and `// +build` compiler directives.
These will also change from the previous muted gray to the keyword
color. This is arguably an improvement — compiler directives are special
constructs that benefit from visible highlighting, consistent with how
other editors (CLion, VS Code) handle them.
## Test plan
- [x] `cargo test -p language highlight_map` passes
- [x] Open a C/C++ file and verify `#include`, `#define`, `#ifdef`, etc.
are highlighted with the keyword color
- [x] Verify across multiple builtin themes (One Dark, Ayu Dark, Gruvbox
Dark, etc.)
- [x] Open a Go file and verify `//go:` directives are highlighted
reasonably
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Release Notes:
- Fixed C/C++ preprocessor directives (`#include`, `#define`, etc.)
appearing unhighlighted in builtin themes.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: MrSubidubi <finn@zed.dev>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes#52926
Follow-up to #48861
cc @SomeoneToIgnore
Release Notes:
- Edited buffers are no longer saved by default before running a task,
but you can still configure this using the "save" field in `tasks.json`.
---------
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- Added the option for highlights from languages to specify fallbacks.
That means that if you have a pattern with the captures `@second.capture
@first.capture`, Zed will first try resolving a highlight from your
theme for the code fragment using the first capture, then look for the
second capture if no match for the first capture could be found.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Make sure we don't try and load a thread we don't have metadata for and
therefore is unlikely to exist
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
We were inserting threads with no entries into the sidebar, when you
clicked on New Thread, typed a message and then added a new project to
the current workspace.
We now skip persisting threads when they are empty.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
This was missing from the previous permissions changes.
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#52882, should help #52723
According to the [Zed
documentation](https://zed.dev/docs/semantic-tokens#example-disabling-a-token-type),
users should be able to disable semantic highlighting for a specific
token type by adding an empty rule in `settings.json`.
However, the current implementation fails to respect this because its
merging logic allows lower-priority default styles to "leak through"
even when a matching high-priority rule is empty. This makes it
impossible to selectively disable semantic tokens to reveal the
underlying Tree-sitter highlighting when using "semantic_tokens":
"combined". This is particularly problematic for extensions that provide
specialized Tree-sitter queries which are currently being obscured by
less desirable semantic tokens(#52723).
This PR fixes the logic to ensure that a completely empty high-priority
rule acts as an opaque override, correctly disabling semantic styling
for that token type and allowing Tree-sitter highlighting to show
through as intended.
Release Notes:
- Fixed a bug where semantic token highlighting could not be disabled
via empty rules in `settings.json`.
Closes#51573Closes#52852 * I believe, looking for verification of that.
A very similar issue was belived to be fixed with #51642 , however it
seems like there is still some edge cases that were causing crashes.
These issues appeared to me to be caused by the dedup method failing to
catch sub-ranges (created by entering SelectMode after the search) as
duplicates.
two new tests that isolate the case in 51573 and 52852 respectively.
fixed vid:
https://github.com/user-attachments/assets/f62d5210-6cb3-4bdf-a061-efc265eb2804
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- helix: Fix search selection range deduplication logic
Closes#46933
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] NO UI CHANGES
Release Notes:
- Fixed `Failed to load shell environment` errors on Windows when users
have custom terminal shell arguments configured (e.g., cmd.exe with `/k
echo Hello` or similar startup commands)
This fixes three pre-existing issues in the visual test runner that were
never caught because visual tests aren't run in CI.
## Fixes
**1. Re-entrant read panic in sidebar creation (3 places)**
`Sidebar::new` reads the `MultiWorkspace` entity, so creating it inside
a `multi_workspace.update()` closure causes a `cannot read while being
updated` panic. Fixed by using `update_window` with
`root_view.downcast()` to get the handle without holding a mutable
borrow.
**2. Tooltip entity leak in breakpoint_hover test**
The tooltip system has an Rc cycle (`ActiveTooltip::Visible` holds a
`check_visible_and_update` closure that captures the
`Rc<RefCell<Option<ActiveTooltip>>>`). This cycle is normally broken
when the tooltip is dismissed, but the test closed the window while the
tooltip was still visible, causing a panic from the leak detector. Fixed
by simulating a click before cleanup to dismiss the tooltip.
**3. Visual tests not in CI**
Added a `cargo_run_visual_tests` step to the macOS test job via xtask so
these tests run on every PR and regressions are caught early.
Release Notes:
- N/A
This PR improves the unreliability of the new top-down flow when editing
previous user messages. Previously, sometimes the thread wouldn't
auto-scroll as you're editing older messages and re-submitting them. It
turns out, the culprit seems to be a bit of a race condition where the
Stopped event (which sets the follow_tail method to false) could still
be emitted a while after a generation has been stopped. So depending on
time, one given possibility could happen. But now, this is what we do:
- If it is still generating, that means the stop/error event is stale
relative to a newer turn, so we do not run the cleanup that disables
follow-tail.
- If it is not generating, then it’s a real completion for the active
turn, and we do the normal cleanup.
---
Release Notes:
- N/A
This PR has us collecting the main worktree path metadata for the
sidebar, allows us to query by that path, and in the interim adds in
logic for querying the main worktree paths. This means that, as this
change percolates, there shouldn't be much difference between opening a
workspace to a linked worktree, and opening a workspace to the main
worktree.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
## Context
This PR introduces a `base` field for settings profiles to allow
profiles to either overlay `user` settings or to overlay `default`,
which is simply zed's defaults (user settings are skipped). I'm not
entirely sure I love `default` because it's a bit confusing (there's a
setting called `default` but the default is `user`). Another idea I had
was `factory` (`user` (default) or `factory`) - curious to hear from the
reviewers. This will be useful for those of us who need to quickly flip
to a default state, or a default state with some customizations on top.
Additionally, from what I can tell, VS Code's profile system is more in
line with what this PR is offering in Zed - profiles overlay the default
settings, not the user's customization layer. So this will be familiar
for those users.
I've had no issue with the migrator, code is pretty simple there, but
would love for @smitbarmase to review the migration to make sure I'm not
missing something.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [X] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [X] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Improved the flexibility of settings profiles by offering a way for
profiles to lay atop of zed defaults, skipping user settings all
together. Settings Profiles now take the following form.
```json5
"Your Profile": {
"base": "user" // or "default"
"settings": {
// ...
},
},
```
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Co-authored-by: Conrad <conrad@zed.dev>
This PR adds a button in the sidebar's recent projects picker to open
the remote projects modal, matching how the recent project modal itself
is. Here's the result:
<img width="400" height="428" alt="Screenshot 2026-04-01 at 7 12@2x"
src="https://github.com/user-attachments/assets/b23ff896-6d42-4ea7-92ba-9d3d092c5f03"
/>
Release Notes:
- N/A
Co-authored-by: Cole Miller <cole@zed.dev>
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Fixes ZED-67X
Fixes ZED-50E
Release Notes:
- N/A
Co-authored-by: Cole Miller <cole@zed.dev>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
## Context
Replaces the native system prompt used for "About Zed" with a custom
standalone GPUI window which can open without the need for opening a Zed
editor window of none are currently open.
Closes#49157
## How to Review
Single file change in `crates/zed/src/zed.rs` — the `about` function is
replaced by `open_about_window`. The new window deduplicates itself,
matches the old layout (title, version info, Ok + Copy buttons), and
closes on either button or Escape.
## Screenshots
### Old Behavior
Opening the about window when no other Zed window is open will open a
new empty zed window and display the about window on top:
<img width="1710" height="1072" alt="image"
src="https://github.com/user-attachments/assets/10a22027-4aa8-4cc9-9d91-368d76bb6a91"
/>
### New Behavior
If there is no open Zed window we just open an instance of the new About
window:
<img width="1710" height="1076" alt="image"
src="https://github.com/user-attachments/assets/e55c92dc-18db-4556-83bd-1a78db754eff"
/>
If there is at least one open Zed window, we display the About window on
top of it:
<img width="1710" height="1075" alt="image"
src="https://github.com/user-attachments/assets/a653e402-a107-4b50-8d09-7d50f537b36c"
/>
In bright mode:
<img width="1710" height="1071" alt="image"
src="https://github.com/user-attachments/assets/c72f8856-7152-47a6-a630-0875372a270f"
/>
Additionally, the ESC button will now act like clicking the Ok button
and close the about window without copying its content.
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- no new tests have been implemented
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Improved the About Zed dialog to open as a standalone window instead
of a native system prompt
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Had been seeing this for some time
<img width="1683" height="167" alt="bad"
src="https://github.com/user-attachments/assets/bd7370c9-617a-45c2-8785-ef268444f00a"
/>
and the culprit turned out to be the fact that the regex matched empty
strings.
The fix changes the regex to ensure it stops matching empty strings, and
patches the `log_err` callsite logic to avoid reading directories.
Release Notes:
- N/A
### Summary
This PR starts work on adding basic hook support in the `TaskStore`. To
enable users to setup tasks that are ran when the agent panel creates a
new git worktree to start a thread in. It also adds a new task variable
called `ZED_MAIN_GIT_WORKTREE` that's the absolute path to the main repo
that the newly created linked worktree is based off of.
### Follow Ups
- Get this hook working with the git worktree picker as well
- Make a more general approach to the hook system in `TaskStore`
- Add `ZED_PORT_{1..10}` task variables
- Migrate the task context creation code from `task_ui` to the basic
context provider
Before you mark this PR as ready for review, make sure that you have:
- [ ] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Previously, within the recent projects modal, the ability to add a
project to the workspace, delete a project from the "this window" or
"recent projects" sections, and remove a project from the current window
were only possible to do with the mouse. This PR enables them with the
keyboard, through buttons/keybindings exposed in the modal's footer and
"actions" menu. Here's a quick video for reference:
https://github.com/user-attachments/assets/b8980ed8-ba32-4e20-93b4-c0a9ea311309
Release Notes:
- Improved keyboard navigation for the recent projects modal.
TODO:
- [x] merge main
- [x] nonshrinking `set_excerpts_for_path`
- [x] Test-drive potential problem areas in the app
- [x] prepare cloud side
- [x] test collaboration
- [ ] docstrings
- [ ] ???
## Context
### Background
Currently, a multibuffer consists of an arbitrary list of
anchor-delimited excerpts from individual buffers. Excerpt ranges for a
fixed buffer are permitted to overlap, and can appear in any order in
the multibuffer, possibly separated by excerpts from other buffers.
However, in practice all code that constructs multibuffers does so using
the APIs defined in the `path_key` submodule of the `multi_buffer` crate
(`set_excerpts_for_path` etc.) If you only use these APIs, the resulting
multibuffer will maintain the following invariants:
- All excerpts for the same buffer appear contiguously in the
multibuffer
- Excerpts for the same buffer cannot overlap
- Excerpts for the same buffer appear in order
- The placement of the excerpts for a specific buffer in the multibuffer
are determined by the `PathKey` passed to `set_excerpts_for_path`. There
is exactly one `PathKey` per buffer in the multibuffer
### Purpose of this PR
This PR changes the multibuffer so that the invariants maintained by the
`path_key` APIs *always* hold. It's no longer possible to construct a
multibuffer with overlapping excerpts, etc. The APIs that permitted
this, like `insert_excerpts_with_ids_after`, have been removed in favor
of the `path_key` suite.
The main upshot of this is that given a `text::Anchor` and a
multibuffer, it's possible to efficiently figure out the unique excerpt
that includes that anchor, if any:
```
impl MultiBufferSnapshot {
fn buffer_anchor_to_anchor(&self, anchor: text::Anchor) -> Option<multi_buffer::Anchor>;
}
```
And in the other direction, given a `multi_buffer::Anchor`, we can look
at its `text::Anchor` to locate the excerpt that contains it. That means
we don't need an `ExcerptId` to create or resolve
`multi_buffer::Anchor`, and in fact we can delete `ExcerptId` entirely,
so that excerpts no longer have any identity outside their
`Range<text::Anchor>`.
There are a large number of changes to `editor` and other downstream
crates as a result of removing `ExcerptId` and multibuffer APIs that
assumed it.
### Other changes
There are some other improvements that are not immediate consequences of
that big change, but helped make it smoother. Notably:
- The `buffer_id` field of `text::Anchor` is no longer optional.
`text::Anchor::{MIN, MAX}` have been removed in favor of
`min_for_buffer`, etc.
- `multi_buffer::Anchor` is now a three-variant enum (inlined slightly):
```
enum Anchor {
Min,
Excerpt {
text_anchor: text::Anchor,
path_key_index: PathKeyIndex,
diff_base_anchor: Option<text::Anchor>,
},
Max,
}
```
That means it's no longer possible to unconditionally access the
`text_anchor` field, which is good because most of the places that were
doing that were buggy for min/max! Instead, we have a new API that
correctly resolves min/max to the start of the first excerpt or the end
of the last excerpt:
```
impl MultiBufferSnapshot {
fn anchor_to_buffer_anchor(&self, anchor: multi_buffer::Anchor) -> Option<text::Anchor>;
}
```
- `MultiBufferExcerpt` has been removed in favor of a new
`map_excerpt_ranges` API directly on `MultiBufferSnapshot`.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Co-authored-by: Conrad <conrad@zed.dev>
This hang was caused by emitting the Git Graph Count Updated event for
every commit being added to the graph instead of every batch of commits.
This would cause gpui to have a massive amount of events to handle on
the foreground thread, even if most of them had very little work
involved.
For example, Zed graph has over 80k commits, that means we were emitting
80k plus events instead of 80.
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
This PR changes `agent.play_sound_when_agent_done` from a boolean to an
enum with three options:
- `never` (default)
- `when_hidden`
- `always`
In Settings → Agent, this now appears as a _Play Sound When Agent Done_
dropdown.
Existing settings are migrated automatically:
- `false` → `never`
- `true` → `always`
### Why
A boolean only allowed the sound to be on or off. This change gives
users clearer control over when the agent notification sound should
play.
### Verification
- Added a migrator test for this setting change.
- Manually tested the settings UI, settings migration and the feature
Release Notes:
- Added new agent notification sound options
---------
Co-authored-by: Oleksiy Syvokon <oleksiy.syvokon@gmail.com>
Self-Review Checklist:
- [ ] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Closes #ISSUE
Release Notes:
- N/A or Added/Fixed/Improved ...
## Summary
- break tooltip back-references from stored callbacks and tasks with
weak handles
- keep the tooltip controller as the sole strong owner of tooltip
lifecycle state
- add a regression test that exercises the visible-tooltip ownership
graph directly
## Testing
- cargo test -p gpui tooltip_is_released_when_its_owner_disappears --lib
Closes AI-120
Release Notes:
- Fixed a tooltip memory leak.
Closes#29757Closes#49387
This PR upgrades ESLint language server from `vscode-eslint 2.4.4` to
upstream `microsoft/vscode-eslint 3.0.24`, and make the workspace
configuration version-aware so ESLint 8, 9, and 10 take the correct
config-mode path.
The key part is that the 3.x bump alone is not enough. This PR keeps Zed
out of that path except where it is still actually needed. Rest
heavy-lifting is done by eslint server itself.
Zed now only overrides ESLint settings in the two known broken cases:
- ESLint 8.21-8.56 flat config: send `experimental.useFlatConfig = true`
- ESLint 9 legacy config: send `useFlatConfig = false`
All other cases defer to `vscode-eslint 3.x`'s own config and
working-directory discovery.
For testing, I created https://github.com/smitbarmase/eslint-repros,
which contains a versioned ESLint repros covering root flat config,
legacy config, and package-local monorepo cases across ESLint 8, 9, and
10. Here is compare between `zed/main`, a pure `vscode-eslint 3.x`
upgrade and this branch with the config-mode fixes:
## zed main
```text
eslint-v8_21-flat-root-single
eslint-v8_56-flat-package-local-monorepo -> breaks on main
eslint-v8_56-flat-root-single
eslint-v8_56-legacy-root-single
eslint-v8_57-flat-package-local-monorepo -> breaks on main
eslint-v8_57-flat-root-single
eslint-v8_57-legacy-root-single
eslint-v9_0-flat-package-local-monorepo
eslint-v9_0-flat-root-single
eslint-v9_0-legacy-root-single -> breaks on main
eslint-v10_0-flat-package-local-monorepo
eslint-v10_0-flat-root-single -> breaks on main
```
## vscode-eslint 3.x upgrade
```text
eslint-v8_21-flat-root-single
eslint-v8_56-flat-package-local-monorepo -> breaks on 3.x upgrade
eslint-v8_56-flat-root-single
eslint-v8_56-legacy-root-single
eslint-v8_57-flat-package-local-monorepo
eslint-v8_57-flat-root-single
eslint-v8_57-legacy-root-single
eslint-v9_0-flat-package-local-monorepo
eslint-v9_0-flat-root-single
eslint-v9_0-legacy-root-single -> breaks on 3.x upgrade
eslint-v10_0-flat-package-local-monorepo
eslint-v10_0-flat-root-single -> breaks on 3.x upgrade
```
## vscode-eslint 3.x upgrade + use flat config fixes
```text
eslint-v8_21-flat-root-single
eslint-v8_56-flat-package-local-monorepo
eslint-v8_56-flat-root-single
eslint-v8_56-legacy-root-single
eslint-v8_57-flat-package-local-monorepo
eslint-v8_57-flat-root-single
eslint-v8_57-legacy-root-single
eslint-v9_0-flat-package-local-monorepo
eslint-v9_0-flat-root-single
eslint-v9_0-legacy-root-single
eslint-v10_0-flat-package-local-monorepo
eslint-v10_0-flat-root-single
```
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed ESLint not reporting diagnostics in some cases for projects that
use flat-config, legacy-config, and monorepo projects across ESLint 8,
9, and 10.
A couple of things that this PR wants to accomplish:
* remove dependency on `settings` crate from `language_model`
* refactor provider-specific code into submodules - to be honest, I
would go one step further and put all provider-specific bits in
`language_models` instead but I realise we have cloud logic in
`language_model` which uses those too making it tricky
* move anthropic-specific telemetry into `language_models` crate - I
think it makes more sense for it to be there
Anyhow, I would very appreciate if you could have a look @mikayla-maki
and @maxdeviant and lemme know what you think, if you would tweak
something, etc.
Release Notes:
- N/A
## Context
Closes#11473
In-house Zed implementation of devcontainers. Replaces the dependency on
the [reference implementation](https://github.com/devcontainers/cli) via
Node.
This enables additional features with this implementation:
1. Zed extensions can be specified in the `customizations` block, via
this syntax in `devcontainer.json:
```
...
"customizations": {
"zed": {
"extensions": ["vue", "ruby"],
},
},
```
2.
[forwardPorts](https://containers.dev/implementors/json_reference/#general-properties)
are supported for multiple ports proxied to the host
## How to Review
<!-- Help reviewers focus their attention:
- For small PRs: note what to focus on (e.g., "error handling in
foo.rs")
- For large PRs (>400 LOC): provide a guided tour — numbered list of
files/commits to read in order. (The `large-pr` label is applied
automatically.)
- See the review process guidelines for comment conventions -->
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Improved devcontainer implementation by moving initialization and
creation in-house
