This PR decouples the `Tool` trait from the `Workspace` (and from the
UI, in general).
`Tool::run` now takes a `WeakEntity<Project>` instead of a
`WeakEntity<Workspace>` and a `Window`.
Release Notes:
- N/A
A preparation for https://github.com/zed-industries/zed/issues/4957 that
pushes all LSP-related data out from the basic completion item, so that
it's possible to create completion items without any trace of LSP
clearly.
Release Notes:
- N/A
This PR updates the `ExtensionBuilder` to require that grammar names are
written in snake_case.
The grammar names are used to construct identifiers, so we need them to
be valid C identifiers.
Release Notes:
- N/A
This PR adds pages to component preview when clicking on a given
component in the sidebar.
This will let us create richer previews & better docs for using
components in the future.
Release Notes:
- N/A
This reduces the number of multibuffer syncs from 100,000 to 20,000.
Before this change each editor individually observed the project, so
literally any project change was amplified by the number of editors you
had open.
Now editors listen to their buffers instead of the project, and other
users of `cx.observe` on the project have been updated to use specific
events to reduce churn.
Follow up to #26237
Release Notes:
- Improved performance of Zed in large repos with lots of file system
events.
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Try to re-order the tips for clarity, and make it clear that /etc/prime
could be wrong either way around.
Also remove section on FIPS now we nolonger bundle openssl
Updates #15629
Release Notes:
- N/A
We're still recreating a session for every tool call, but the idea is to
have a long-lived `Session` per assistant thread.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Closes#24741
Adjusted the shortcut key handling to properly toggle filters in the project search feature.
Release Notes:
- linux: Fixed `ctrl-alt-f` not correctly toggling search filters in project search.
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
## Problem
Running `cargo run .` twice in Zed repository required a rebuild two
times in a row. The second rebuild was triggered around libz-sys, which
in practice caused a rebuild of the ~entire project.
Some concrete examples:
```
cargo test -p project # Requires a rebuild (warranted)
cargo run .
cargo test -p project # Requires a rebuild (unwarranted)
```
or
```
cargo run . # Requires a rebuild (warranted)
cargo run . # Requires a rebuild (unwarranted)
```
## What's going on
Zed build script on MacOS sets MACOSX_DEPLOYMENT_TARGET to 10.15. This
is fine. However, **cargo propagates all environment variables to child
processes during `cargo run`**. This then affects Rust Analyzer spawned
by dev Zed - it clobbers build cache of whatever package it touches,
because it's behavior is not same between running it with `cargo run`
(where MACOS_DEPLOYMENT_TARGET gets propagated to child Zed) and running
it directly via `target/debug/zed` or whatever (where the env variable
is not set, so that build behaves roughly like Zed Dev.app).
## Solution
~We'll unset that env variable from user environment when we're
reasonably confident that we're running under `cargo run` by exploiting
other env variables set by cargo:
https://doc.rust-lang.org/cargo/reference/environment-variables.html
CARGO_PKG_NAME is always set to `zed` when running it via `cargo run`,
as it's the value propagated from the build.~
~The alternative I've considered is running [via a custom
runner](https://doc.rust-lang.org/cargo/reference/config.html#targetcfgrunner),
though the problem here is that we'd have to use a shell script to unset
the env variable - that could be problematic with e.g. fish. I just
didn't want to deal with that, though admittedly it would've been
cleaner in other aspects.~
Redact all above. We'll just set MACOSX_DEPLOYMENT_TARGET regardless of
whether you have it in your OG shell environment or not.
Release Notes:
- N/A
Closes#20291
This PR removes the plain text file association from the default
settings, as #21298 added a `LanguageMatcher` for Plain Text files,
which now associates "Plain Text" with `txt`-files (see
10053e2566/crates/language/src/language.rs (L127-L137)).
Thus, the association via the default settings is not required anymore,
which fixes#20291 as described in
https://github.com/zed-industries/zed/issues/20291#issuecomment-2500731743
Release Notes:
- Fixed default file type associations overriding associations provided
by extensions for `txt`-files.
Co-authored-by: Peter Tripp <peter@zed.dev>
205f9a9f03/crates/editor/src/element.rs (L1643)
Due to the snippet above, Zed is supposed to have `row` larger or equal
to `start_row` here:
205f9a9f03/crates/editor/src/element.rs (L1694)
yet the panic were reported when clicking in the project diff.
That project diff has a lot of highlighting happening already, so the PR
disables inline diagnostics within a git diff view.
Release Notes:
- N/A
Access to `cx` will be needed for anything that queries entities. In
this commit this is use of `WorktreeStore::find_search_candidates`. In
the future it will be things like access to LSP / tree-sitter outlines /
etc.
Changes to support access to `cx` from functions provided to the Lua
script:
* Adds a channel of requests that require a `cx`. Work enqueued to this
channel is run on the foreground thread.
* Adds `async` and `send` features to `mlua` crate so that async rust
functions can be used from Lua.
* Changes uses of `Rc<RefCell<...>>` to `Arc<Mutex<...>>` so that the
futures are `Send`.
One benefit of reusing project search logic for search candidates is
that it properly ignores paths.
Release Notes:
- N/A
Closes#26062
Removing the width here causes zed to use the default value (inside
default settings) after restart like other panels.
Release Notes:
- Fixed issue where git panel wasn't using default width after restart
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This PR adds a few more hunk style settings that flips the emphasis.
Normally, the concept at Zed has been that the project diff should
emphasize what's going into the commit. However, this leads to a problem
where the default state of all diff hunks are in the non-emphasized
state, making them hard to see and interact with. Especially on light
themes. This PR is an experiment in flipping the emphasis states. Now
the project diff is more like a queue of work, with the next "job" (hunk
to be evaluated) emphasized, and the "completed" (staged) hunks
deemphasized. This fixes the default state issue but is a big jump from
how we've been thinking about it. So here we can try it out and see how
it feels :)
Release Notes:
- Git Beta: Added hunk style settings to emphasize the unstaged state,
rather than the staged state.
Modified version of #25950. We still use worktree paths, but repo paths
with a status that lie outside the worktree are not excluded; instead,
we relativize them by adding `..`. This makes the list in the git panel
match what you'd get from running `git status` (with the repo's worktree
root as the working directory).
- [x] Implement + test new unrelativization logic
- [x] ~~When collecting repositories, dedup by .git abs path, so
worktrees can share a repo at the project level~~ dedup repos at the
repository selector layer, with repos coming from larger worktrees being
preferred
- [x] Open single-file worktree with diff when activating a path not in
the worktree
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/24914 (again)
Release Notes:
- Fixed an issue where multi-line pasted content was auto-indented
incorrectly if copied from the middle of an existing line.
This reduces the number of multibuffer syncs when starting the editor
with 80
files open in the Zed repo from 10,000,000 to 100,000 by avoiding
O(n**2)
dirtyness checks.
Release Notes:
- Fixed a beachball when restarting in a large repo with a large number
open files
This PR removes a number of `.unwrap`s in the Bedrock provider.
We must not `.unwrap` in situations where it is not provably safe to do
so, which it was not in any of these cases.
Release Notes:
- Fixed some potential panics in the AWS Bedrock model provider.
https://github.com/user-attachments/assets/b16e32e6-46c6-41dc-ab68-1824d288c8c2
This PR adds the first part of our planned extended notification system:
StatusToasts.
It also makes various updates to ComponentPreview and adds a `Styled`
extension in `ui::style::animation` to make it easier to animate styled
elements.
_**Note**: We will be very, very selective with what elements are
allowed to be animated in Zed. Assume PRs adding animation to elements
will all need to be manually signed off on by a designer._
## Status Toast
These are designed to be used for notifying about things that don't
require an action to be taken or don't need to be triaged. They are
designed to be ignorable, and dismiss themselves automatically after a
set time.
They can optionally include a single action.
Example: When the user enables Vim Mode, that action might let them undo
enabling it.
Status Toasts should _not_ be used when an action is required, or for
any binary choice.
If the user must provide some input, this isn't the right component!
### Out of scope
- Toasts should fade over a short time (like AnimationDuration::Fast or
Instant) when dismissed
- We should visually show when the toast will dismiss. We'll need to
pipe the `duration_remaining` from the toast layer -> ActiveToast to do
this.
- Dismiss any active toast if another notification kind is created, like
a Notification or Alert.
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <m@cole-miller.net>
This PR finishes up the support for generating commit messages using an
LLM.
We're shelling out to `git diff` to get the diff text, as it seemed more
efficient than attempting to reconstruct the diff ourselves from our
internal Git state.
https://github.com/user-attachments/assets/9bcf30a7-7a08-4f49-a753-72a5d954bddd
Release Notes:
- Git Beta: Added support for generating commit messages using a
language model.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR adds a new rounded/corner border token: `rounded_md` with a
value of 6px.
I feel like I was wanting to use 6px border radius a lot but avoiding
due to it being an arbitrary value... so, not anymore! It's also cool to
have this be consistent with Tailwind v4.
Follow on to the prior renames:
- `rounded_sm` -> `rounded_xs`:
https://github.com/zed-industries/zed/pull/26221
- `rounded_md` -> `rounded_sm`:
https://github.com/zed-industries/zed/pull/26228
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
There is a drawback to how we currently write our migrations:
For example:
1. Suppose we change one of our actions from a string to an array and
rename it, then roll out the preview build:
Before: `"ctrl-x": "editor::GoToPrevHunk"`
Latest: `"ctrl-x": ["editor::GoToPreviousHunk", { "center_cursor": true
}]`
To handle this, we wrote migration `A` to convert the string to an
array.
2. Now, suppose we decide to change it back to a string:
- User who hasn't migrated yet on Preview: `"ctrl-x":
"editor::GoToPrevHunk"`
- User who has migrated on Preview: `"ctrl-x":
["editor::GoToPreviousHunk", { "center_cursor": true }]`
- Latest: `"ctrl-x": "editor::GoToPreviousHunk"`
To handle this, we would need to remove migration `A` and add two more
migrations:
- **Migration B**: `"ctrl-x": "editor::GoToPrevHunk"` -> `"ctrl-x":
"editor::GoToPreviousHunk"`
- **Migration C**: `"ctrl-x": ["editor::GoToPreviousHunk", {
"center_cursor": true }]` -> `"ctrl-x": "editor::GoToPreviousHunk"`
Nice. But over time, this keeps increasing, making it impossible to
track outdated versions and handle all cases. Missing a case means users
stuck on `"ctrl-x": "editor::GoToPrevHunk"` will remain there and won't
be automatically migrated to the latest state.
---
To fix this, we introduce versioned migrations. Instead of removing
migration `A`, we simply write a new migration that takes the user to
the latest version—i.e., in this case, migration `C`.
- A user who hasn't migrated before will go through both migrations `A`
and `C` in order.
- A user who has already migrated will only go through `C`, since `A`
wouldn't change anything for them.
With incremental migrations, we only need to write migrations on top of
the latest state (big win!), as know internally they all would be on
latest state. You *must not* modify previous migrations. Always create
new ones instead.
This also serves as base for only prompting user to migrate, when
feature reaches stable. That way, preview and stable keymap and settings
are in sync.
cc: @mgsloan @ConradIrwin @probably-neb
Release Notes:
- N/A
This PR adds support for capabilities for the extension process API.
In order to use the process API, an extension must declare which
commands it wants to use, with arguments:
```toml
[[capabilities]]
kind = "process:exec"
command = "echo"
args = ["hello!"]
```
A `*` can be used to denote a single wildcard in the argument list:
```toml
[[capabilities]]
kind = "process:exec"
command = "echo"
args = ["*"]
```
And `**` can be used to denote a wildcard for the remaining arguments:
```toml
[[capabilities]]
kind = "process:exec"
command = "ls"
args = ["-a", "**"]
```
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR improves the setup instructions for the slash-commands-example
extension by:
1. Replacing the `sed` command with a more reliable approach that
completely replaces the Cargo.toml file.
2. Explicitly showing how to create a standalone extension with a
properly configured Cargo.toml file that:
- Uses `edition = "2021"` instead of `edition.workspace = true`
- Doesn't include `publish.workspace = true`
- Doesn't include the `[lints]` section
This change addresses an issue where the extension wouldn't work when
copied as a standalone project due to workspace references that are only
valid when the extension is built as part of the main Zed repository.
The updated instructions provide a clear, reliable path for developers
to create their own Zed extensions based on the slash commands example.
Release Notes:
- N/A
