When doing a project wide search in zed on windows for `hang`, zed
starts to freeze for a couple seconds ultimately starting to error with
`Not enough quota is available to process this command.` when
dispatching windows messages. The cause for this is that we simply
overload the windows message pump due to the sheer amount of foreground
tasks we spawn when we populate the project search.
This PR is an attempt at reducing this.
Release Notes:
- Reduced hangs and stutters in large project file searches
This ensures the thread summary is treated as a tracked mention with
accessible context.
Changes:
- Fixed `MessageEditor::insert_thread_summary()` to use proper mention
URI format
- Added test coverage to verify the fix
Release Notes:
- Fixed an issue where "New From Summary" was not properly inserting
thread summaries as contextual mentions when creating new threads.
Thread summaries are now inserted as proper mention URIs.
Attempt 2 for https://github.com/zed-industries/zed/pull/40774
We were spawning the process on the foreground thread before which can
block an arbitrary amount of time. Likewise we no longer block
deserialization on the terminal loading.
Release Notes:
- Improved startup time on systems with slow process spawning
capabilities
Adds an action to open the notes for the currently selected channel in
the collab panel, which is mapped to `alt-enter` in all platforms.
Release Notes:
- collab: Add `collab_panel::OpenSelectedChannelNotes` action
(`alt-enter` by default)
Add default keybinding for `pane::SplitRight` in the `Terminal` context
for all platforms.
Closes #ISSUE
Release Notes:
- Added VS Code's terminal split keybindings (`cmd` on MacOS,
`ctrl-shift-5` on Windows and Linux)
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
I just pulled and ran a local build via `script/bundle-mac -l -i` but
found that the resulting bundle wasn't installed as expected. (me:
"ToggleAllDocks!! Wait! Where is it?!") Looking into, it looks like the
`-l` flag was removed in #41392, leaving the `$local_only` var orphaned,
which then left the `-i/$local_install` flag unreachable. I suspect that
this was unintentional, so this PR re-adds the `-l/$local_only` flag to
`script/bundle-mac`.
I ran the build again and confirmed that local install seemed to work as
expected. (ie "ToggleAllDocks!! 🎉")
While here, I also removed the last reference to `$local_arch`, because
all other references to that were removed in #41392.
/cc @osiewicz
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
We'll now perform all searches from the context model concurrently, and
combine queries for the same glob into one reducing the total number of
project searches.
For better readability, the debug context view now displays each
top-level regex alternation individually, grouped by its corresponding
glob:
<img width="1592" height="672" alt="CleanShot 2025-10-29 at 19 56 03@2x"
src="https://github.com/user-attachments/assets/f6e8408e-09d6-4e27-ba11-a739a772aa12"
/>
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/39104
This fixes an issue where the preview would not work for remote buffers
in the process.
Release Notes:
- Fixed an issue where the SVG preview would not work in remote
scenarios.
- The SVG preview will now rerender on every keypress instead of only on
saves.
Closes#41180
When using the fallback prompt renderer (default on Wayland), clicks
would bleed through into underlying windows. When the click happens to
hit a button that creates a prompt, it drops the
`RenderablePromptHandle` which is contained within `Window`, causing the
`Receiver` which returns the index of the clicked `PromptButton` to
return `Err(Canceled)` even though a button was pressed.
This bug appears in the GPUI `window.rs` example, which can be ran using
`cargo run -p gpui --example window`. MacOS has a native
`PromptRenderer` and thus needs additional code to be adjusted to be
able to reproduce the issue.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Release Notes:
- settings_ui: Added the ability to copy a link to a given setting,
allowing users to quickly open the settings window at the correct
location in a faster way.
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Added a "Clear Messages" button to the ACP logs toolbar that removes all
messages.
## Motivation
When debugging ACP protocol implementations, the message list can become
cluttered with old messages. This feature allows clearing all messages
with a single click to start fresh, making it easier to focus on new
interactions without closing and reopening the ACP logs view.
Release Notes:
- N/A
This reintroduces `layer_shell` support after #32651 was reverted. On
top of that, it allows setting options for the created surface,
restricts the enum variant to the `wayland` feature, and adds an example
that renders a clock widget using the protocol.
I've renamed the `WindowKind` variant to `LayerShell` from `Overlay`,
since the protocol can also be used to render wallpapers and such, which
doesn't really fit with the word.
Things I'm still unsure of:
- We need to get the layer options types to the user somehow, but
nothing from the `platform::linux` crate was exported, I'm assuming
intentionally. I've kept the types inside the module (instead of doing
`pub use layer_shell::*` to not pollute the global namespace with
generic words like `Anchor` or `Layer` Let me know if you want to do
this differently.
- I've added the options to the `WindowKind` variant. That's the only
clean way I see to supply them when the window is created. This makes
the kind no longer implement `Copy`.
- The options don't have setter methods yet and can only be defined on
window creation. We'd have to make fallible functions for setting them,
which only work if the underlying surface is a `layer_shell` surface.
That feels un-rust-y.
CC @zeroeightysix
Thanks to @wuliuqii, whose layer-shell implementation I've also looked
at while putting this together.
Release Notes:
- Add support for the `layer_shell` protocol on wayland
---------
Co-authored-by: Ridan Vandenbergh <ridanvandenbergh@gmail.com>
Closes#41407
This solves a problem where users couldn't navigate between snippet
tabstops while the completion menu was open.
I named the action {Next, Previous}SnippetTabstop instead of Placeholder
to be more inline with the LSP spec naming convention and our codebase
names.
Release Notes:
- Editor: Add actions to move between snippet tabstop positions
Closes https://github.com/zed-industries/zed/issues/38558
The bug occurred because TabStopCursor chunk_position.1 is bounded
between 0 and 128. The fix for this was changing the bound to 0 and 127.
This also allowed me to simplify some of the tab stop cursor code to be
a bit faster (less branches and unbounded shifts).
Release Notes:
- N/A
This happens quite often with cargo based diagnostics which may spawn
several lines (sometimes the entire screen), forcing the user to scroll
up to the start of the diagnostic just to see the hover message is not
great.
Release Notes:
- Fixed diagnostics hovers not working if the diagnostic spans out of
view
Just for parity with vim. Also prevents these toggles from having both
enabled at the same time as that is a buggy state.
Release Notes:
- Added command to toggle helix mode
Closes#41422
This completely broke line numbering as described in the linked issue
and scrolling up does not have the correct numbers any more.
Release Notes:
- NOTE: The `relative_line_numbers` change
(https://github.com/zed-industries/zed/pull/39268) was reverted and did
not make the release cut!
Lukas Wirth