Closes #ISSUE
Release Notes:
- Fixed a crash when screensharing on MacOS
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
While working on implementing `add_recent_documents` for Windows, I
found that the process is significantly more complex compared to macOS.
On macOS, simply registering the `add_recent_documents` function is
enough, as the system handles everything automatically.
On Windows, however, there are two cases to consider:
- **Files opened by the app**: These appear in the "Recent" section (as
shown in the screenshot, "test.txt") and are managed automatically by
Windows (by setting windows registry), similar to macOS.
- **Folders opened by the app**: This is more complicated because
Windows does not handle it automatically, requiring the application to
track opened folders manually.
To address this, this PR introduces a `History Manager` along with
`HistoryManagerEvent::Update` and `HistoryManagerEvent::Delete` events
to simplify the process of managing recently opened folders.
https://github.com/user-attachments/assets/a2581c15-7653-4faf-96b0-7c48ab1dcc8d
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This PR lightly refactors the `EditorMode::Full` exposing two new
methods: `is_full` and `set_mode`.
Motivation is to expose fields that modify the behavior when the editor
is in `Full` mode. By using is `mode.is_full()` instead of
`EditorMode::Full` we can introduce new fields without breaking other
places in the code.
Release Notes:
- N/A
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Reimplemented logic from `env_logger` to parse log configuration from
environment variables.
Had to re-implement instead of using `env_filter` crate that
`env_logger` uses, as it does not export the information required to
integrate it.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR introduces support for a `--user-data-dir` CLI flag to override
Zed's data directory and proposes renaming `support_dir` to `data_dir`
for better cross-platform clarity. It builds on the discussion in #25349
about custom data directories, aiming to provide a flexible
cross-platform solution.
### Changes
The PR is split into two commits:
1. **[feat(cli): add --user-data-dir to override data
directory](https://github.com/zed-industries/zed/pull/26886/commits/28e8889105847401e783d1739722d0998459fe5a)**
2. **[refactor(paths): rename support_dir to data_dir for cross-platform
clarity](https://github.com/zed-industries/zed/pull/26886/commits/affd2fc606b39af1b25432a688a9006229a8fc3a)**
### Context
Inspired by the need for custom data directories discussed in #25349,
this PR provides an immediate implementation in the first commit, while
the second commit suggests a naming improvement for broader appeal.
@mikayla-maki, I’d appreciate your feedback, especially on the rename
proposal, given your involvement in the original discussion!
### Testing
- `cargo build `
- `./target/debug/zed --user-data-dir ~/custom-data-dir`
Release Notes:
- Added --user-data-dir CLI flag
---------
Signed-off-by: Marko Kungla <marko.kungla@gmail.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [mimalloc](https://redirect.github.com/purpleprotocol/mimalloc_rust) |
dependencies | patch | `0.1.45` -> `0.1.46` |
---
### Release Notes
<details>
<summary>purpleprotocol/mimalloc_rust (mimalloc)</summary>
###
[`v0.1.46`](https://redirect.github.com/purpleprotocol/mimalloc_rust/releases/tag/v0.1.46):
Version 0.1.46
[Compare
Source](https://redirect.github.com/purpleprotocol/mimalloc_rust/compare/v0.1.45...v0.1.46)
##### Changes
- Fixed musl builds.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
Release Notes:
- N/A
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4yMjcuMyIsInVwZGF0ZWRJblZlciI6IjM5LjIzOC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Was chatting with @wilhelmklopp, he pointed out that our current
UI-accessible way to access the project search was pretty obscure.
<img width="393" alt="Screenshot 2025-04-08 at 6 57 51 PM"
src="https://github.com/user-attachments/assets/636053cd-5a88-4a5e-8155-6d41d189b7db"
/>
Release Notes:
- Added a button to open the project search to the status bar
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Swift bindings BEGONE
Release Notes:
- Switched from using the Swift LiveKit bindings, to the Rust bindings,
fixing https://github.com/zed-industries/zed/issues/9396, a crash when
leaving a collaboration session, and making Zed easier to build.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Michael Sloan <michael@zed.dev>
This is a clean-up PR in anticipation of introduction of Debugger
Registry. I wanna get rid of DebugAdapterKind (or rather, it being an
enum).
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Anthony <anthony@zed.dev>
This PR makes the "Inline Assist" quick action in the quick action bar
work by dispatching the `InlineAssist` action.
This fixes an issue where the button was not working with Assistant 2.
Release Notes:
- N/A
Adds the `--system-specs` flag to the Zed binary, so that users who wish
to report issues can retrieve their system specs, even if Zed is failing
to launch
Still TODO:
- [x] Test and do best effort GPU info detection on Linux
- [ ] Modify GitHub issue templates to tell users that the flag is
available if they are unable to launch Zed
Release Notes:
- Added the `--system-specs` flag to the Zed binary (not the cli!), to
retrieve the system specs we ask for in GitHub issues without needing to
open Zed
Scaffolding for a revised way of logging in Zed. Very WIP, but the idea
is to allow maintainers to tell users to paste
```json
{
"log": {
"project.format": "trace"
}
}
```
into their settings so that even trace logs are emitted for the log
statements emitted from a logger under the `project.format` scope.
The plan is to eventually implement the `Log` trait from the `log` crate
instead of just wrapping the `log` crate, which will simplify the
implementation greatly, and remove our need for both the `env_logger`
and `simplelog` crates.
Additionally, work will be done to transition to using the scoped
logging APIs throughout the app, focusing on bug hotspots to start
(currently, scoped logging is only used in the format codepath).
Release Notes:
- N/A
This PR adds the ability to open the extensions view via the `zed:
extensions` action with a pre-selected filter.
The "Install Themes" and "Install Icon Themes" buttons in their
respective selectors take advantage of this to set the filter when
opening the view:
https://github.com/user-attachments/assets/2e345c0f-418a-47b6-811e-cabae6c616d1
Release Notes:
- N/A
This pull request does two things:
1. Adds a setting to force Zed to use the built-in prompts, instead of
the system provided ones. I've personally found the system prompts on
macOS often fail to respond to keyboard input, are slow to render
initially, and don't match Zed's style.
2. Makes the previously Linux-only Zed provided prompts available to
everybody using the above setting.
Release Notes:
- Added support for a built-in prompting system, regardless of platform.
Use the new `use_system_prompts` setting to control whether to use the
system provided prompts or Zed's built-in system. Note that on Linux,
this setting has no effect, as Linux doesn't have a system prompting
mechanism.
This is the core change:
https://github.com/zed-industries/zed/pull/26758/files#diff-044302c0d57147af17e68a0009fee3e8dcdfb4f32c27a915e70cfa80e987f765R1052
TODO:
- [x] Use AsyncFn instead of Fn() -> Future in GPUI spawn methods
- [x] Implement it in the whole app
- [x] Implement it in the debugger
- [x] Glance at the RPC crate, and see if those box future methods can
be switched over. Answer: It can't directly, as you can't make an
AsyncFn* into a trait object. There's ways around that, but they're all
more complex than just keeping the code as is.
- [ ] Fix platform specific code
Release Notes:
- N/A
### DISCLAIMER
> As of 6th March 2025, debugger is still in development. We plan to
merge it behind a staff-only feature flag for staff use only, followed
by non-public release and then finally a public one (akin to how Git
panel release was handled). This is done to ensure the best experience
when it gets released.
### END OF DISCLAIMER
**The current state of the debugger implementation:**
https://github.com/user-attachments/assets/c4deff07-80dd-4dc6-ad2e-0c252a478fe9https://github.com/user-attachments/assets/e1ed2345-b750-4bb6-9c97-50961b76904f
----
All the todo's are in the following channel, so it's easier to work on
this together:
https://zed.dev/channel/zed-debugger-11370
If you are on Linux, you can use the following command to join the
channel:
```cli
zed https://zed.dev/channel/zed-debugger-11370
```
## Current Features
- Collab
- Breakpoints
- Sync when you (re)join a project
- Sync when you add/remove a breakpoint
- Sync active debug line
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Restart stack frame (if adapter supports this)
- Variables
- Loaded sources
- Modules
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Debug console
- Breakpoints
- Log breakpoints
- line breakpoints
- Persistent between zed sessions (configurable)
- Multi buffer support
- Toggle disable/enable all breakpoints
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Show collapsed stack frames
- Restart stack frame (if adapter supports this)
- Loaded sources
- View all used loaded sources if supported by adapter.
- Modules
- View all used modules (if adapter supports this)
- Variables
- Copy value
- Copy name
- Copy memory reference
- Set value (if adapter supports this)
- keyboard navigation
- Debug Console
- See logs
- View output that was sent from debug adapter
- Output grouping
- Evaluate code
- Updates the variable list
- Auto completion
- If not supported by adapter, we will show auto-completion for existing
variables
- Debug Terminal
- Run custom commands and change env values right inside your Zed
terminal
- Attach to process (if adapter supports this)
- Process picker
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Disconnect
- Restart
- Stop
- Warning when a debug session exited without hitting any breakpoint
- Debug view to see Adapter/RPC log messages
- Testing
- Fake debug adapter
- Fake requests & events
---
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Piotr Osiewicz <peterosiewicz@gmail.com>
Co-authored-by: Piotr <piotr@zed.dev>
Release Notes:
- Multibuffers now use less vertical space for excerpt boundaries.
Additionally the expand up/down arrows are hidden at the start and end
of the buffers
---------
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Zed AI <claude-3.5-sonnet@zed.dev>
This PR cleans up some color & elevation misc.
### Don't allow deriving Color from Hsla
The point of the [ui::Color] enum is to encourage consistent color
usage, and the the Color::Custom case is really only meant for cases
where we have no other choice.
`impl From<Hsla> for Color` encourages blindly passing colors into
`Color::Custom` – with this in place we might as well remove the entire
`Color` enum.
The usages that were updated due to this removal were for colors that
already exist in the Color enum, making it even more clear that it
didn't make sense to have this.
### `ElevationIndex` -> `Elevation`
This name would make more sense if we had an `Elevation` in the first
place. The new name is more clear.
#### `Button::elevation`
As part of this change I also updated button's `layer` method to
`elevation`, since it takes an elevation. This method still has the
following issue:
You want to use `Button::elevation` when it's default colors are
invisible on the layer you are rendering the button on. However, current
this method uses the elevation's `bg` color, rather than it's
`on_elevation_bg`.
Ideally when you use `Button::elevation` you want to pass the elevation
you are _on_, not choosing one that will show up the elevation you are
on.
This change will be in a separate PR, as it likely will have widespread
visual impact across the app.
Release Notes:
- N/A
