# Objective
A column's filter popover grays out values that would leave zero rows
given other active filters.
That check only looked at columns filtered _before_ the one being
viewed, so reopening a filter on a column filtered earlier than another
still-active one showed a value as available with count `0` —
selectable, but guaranteed to empty the table.
Separately, values already checked when they became blocked lost their
checkmark and couldn't be unchecked from the popover (matches IntelliJ's
reference behavior of always keeping values checkable with an honest
count, never fully disabled).
## Solution
- Availability now reuses the same `rows_passing_other_filters` set
already used for counts (every other active column's filter, own filter
excluded) instead of the old order-dependent cascade over
`activation_order`. Removed `activation_order` entirely — now dead code.
- `Unavailable` carries `is_applied`, same as `Available`.
Hidden-and-applied rows stay checked and toggleable (to uncheck); only
hidden-and-unapplied rows stay disabled.
- Filter popover footer no longer disappears when a filter's count drops
to `0` (`has_active_filters` instead of `selected_rows == 0`).
## Testing
Fixture:
```csv
A,C
1,red
2,red
1,blue
1,blue
```
Rendered as:
<img width="381" height="165" alt="image"
src="https://github.com/user-attachments/assets/fc12d1d3-26e6-4f8e-97f0-5522f67e70ea"
/>
Manual:
apply filters:
- C=red,blue
- A=2
reopening C's popover shows the blocked `blue` value grayed with count
`0`, stays checked and uncheckable.
## Demo
| Before (counds not updated) | After (counts reflect reality) |
| --- | --- |
| <img width="631" height="190" alt="image"
src="https://github.com/user-attachments/assets/df433449-826d-4f7e-8c35-d3779911b7fa"
/> | <img width="615" height="217" alt="image"
src="https://github.com/user-attachments/assets/ce067fb9-3fd5-4d2a-9689-8defc587f617"
/> |
Release Notes:
- Fixed CSV preview column filters showing incorrect availability/counts
depending on which filter was applied first
# Objective
Fixes#62529.
Prevent Python toolchain discovery from executing Apple's
`/usr/bin/python3` Command Line Tools shim when no active developer
Python exists. Executing that unresolved shim causes macOS to repeatedly
prompt users to install the Command Line Tools, even when Python is
managed through Nix, uv, or pyenv.
## Solution
Update Python Environment Tools (PET) to `bb8e046`, which includes
microsoft/python-environment-tools#506. That upstream change resolves
active Xcode and Command Line Tools Python executables from filesystem
state and skips unresolved macOS system Python shims before generic
process probing.
Adapt Zed to the updated PET API by:
- displaying the newly supported Hatch environment kind
- passing no refresh identifier when running in-process environment
discovery
## Testing
- `cargo check -p languages --locked`
- PET unit tests covering unresolved macOS system Python shims
- The Zed compilation check was run on Linux; the original dialog
reproduction was not manually tested on macOS.
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed Python toolchain discovery prompting installation of Apple
Command Line Tools when using a separately managed Python installation.
This PR bumps the version of the Proto extension to v0.3.3.
Release Notes:
- N/A
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Spotted
```
The package `block v0.1.6` currently triggers the following future incompatibility lints:
> warning: static of uninhabited type
> --> .../block-0.1.6/src/lib.rs:64:5
> |
> 64 | static _NSConcreteStackBlock: Class;
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> = note: uninhabited statics cannot be initialized, and any access would be an immediate error
> = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
> = note: for more information, see issue #74840 <https://github.com/rust-lang/rust/issues/74840>
The package `proc-macro-error2 v2.0.1` currently triggers the following future incompatibility lints:
> warning[E0365]: extern crate `proc_macro` is private and cannot be re-exported
> --> .../proc-macro-error2-2.0.1/src/lib.rs:494:13
> |
> 494 | pub use proc_macro;
> | ^^^^^^^^^^
> |
> = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
> = note: for more information, see issue #127909 <https://github.com/rust-lang/rust/issues/127909>
> help: consider making the `extern crate` item publicly accessible
> |
> 277 | pub extern crate proc_macro;
> | +++
```
warnings recently.
The former is impossible to fix quickly as needs a migration to `objc2`,
but the latter is easily fixed by a version bump, ergo this PR.
Release Notes:
- N/A
While building Zed with nightly rustc I've noticed it doesn't compile
because of good old pathfinder_simd. It also emits a bunch of warnings
about use of f64 literals where f32 is expected, so I've fixed them - it
should make future upgrades more straightforward.
## Objective
Add functional horizontal scrollbars to wide Markdown tables, matching
the existing code-block scrollbar pattern.
Fixes#61437
PR was talked about in https://github.com/zed-industries/zed/pull/61698
## Implementation:
- Added a `BTreeMap<usize, ScrollHandle>` to `Markdown` for table scroll
handles, keyed by source-range start.
- During `MarkdownElement` layout, each table container is connected to
a `Scrollbars` widget configured for the horizontal axis, using a stable
ID derived from `("markdown-table-scrollbar", range.start)`.
- The inner table div uses `overflow_x_scroll()` + `track_scroll()` with
`restrict_scroll_to_axis`.
- Handles for removed tables are discarded after re-rendering.
- No public API, setting, schema, or migration changes required.
## Recording
https://github.com/user-attachments/assets/cd0f635b-a485-4de8-9059-40a05f256fb1
## Release Notes:
- Improved navigation of wide Markdown tables with horizontal
scrollbars.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Enables zooming of mermaid diagrams by supporting horizontal scroll
---
Release Notes:
- improved: Mermaid diagrams can now be zoomed and horizontally
scrolled, in both the markdown preview and the agent panel
Removes an unnecessary dependency on settings as
`settings::OpenAiReasoningEffort` just points to
`language_model::ReasoningEffort`
Release Notes:
- N/A
Currently gpui only supports webgpu as a backend when compiling for the
web. However, webgpu support on Linux browsers is spotty (without
setting experimental flags):
- chromium has is enabled for nvidia and recent intel chips
- firefox does not enable it
This PR adds a WebGL backend, which is much more widely supported
---
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments (N/A)
- [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
I was unable to find an issue or PR which mentions this.
Extensions with non-GitHub repository links always use the GitHub icon,
which is inconsistent with the changes merged in #44738 and #57500. This
change makes `extension_ui.rs` use the Git hosting provider registry to
determine these icons. Below is a preview of the change:
<div align="center">
<img
width="450"
alt="Preview"
src="https://github.com/user-attachments/assets/e35f0eed-de54-48f9-824d-8a5b9bfc596f"
/>
</div>
Release Notes:
- Improved extension repository links to show provider-specific icons.
# Objective
Ensure that the Project Panel's Undo/Redo system is enabled in Stable
before this week's release, as it's enabled on all release channels
except stable.
Since, as far as I'm aware, there hasn't been any issue reported
regarding last week's Preview release, I'm going to go ahead and enable
this in stable.
## Solution
Update
`feature_flags::flags::ProjectPanelUndoRedoFeatureFlag::enabled_for_all`
to `true`, we no longer need to match on the release channel.
## Testing
N/A
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
There is a bug on main and preview causes all terminal tool calls to
fail when:
- on windows
- sandboxing is not available (i.e. no WSL)
- sandboxing is enabled in settings (the default)
- the "warn windows-drive grants" setting is enabled (the default)
Example error:
<img width="352" height="79" alt="image"
src="https://github.com/user-attachments/assets/24affbec-f086-40eb-8827-ad74aabc6167"
/>
This PR fixes it by making sure we only show the check at the right time
---
Release Notes:
- N/A or Added/Fixed/Improved ...
Splits the crate graph.
Before, the compilation graph: `editor → picker_preview → search →
project_panel → open_path_prompt → recent_projects → title_bar →
collab_ui → zed`
After, the compilation graph: `editor → picker_preview → search →
agent_ui → sidebar → zed`
With sccache disabled and project fully built, `touch
crates/editor/src/editor.rs` and `cargo build -p zed` took time
Before (5e1fd392f6): 13.19s
After: 11.85s (-10.2% speed up)
Each commit contains a separate compilation instructions, and a test in
the final commit.
The main approach is to split coupled crates and replace them with
`zed_actions` and move some shared functionality into `git_ui_core` new,
shared module.
I've also tried to add a test to prevent common pitfalls, but not sure
I'm happy with the end result — can remove it if it looks too synthetic.
Release Notes:
- N/A
# Objective
Fixes#60873.
`projects::OpenRemote` has two handling paths:
- The remote-project picker handles `from_existing_connection: false`.
- The active remote workspace handles `from_existing_connection: true`.
The existing-connection path ignored the action’s `create_new_window`
field. Consequently, selecting another project from an active SSH
workspace always created a new OS window—even when:
- the action explicitly specified `create_new_window: false`, or
- `create_new_window` was omitted and `default_open_behavior` was set to
`"existing_window"`.
The expected behavior is:
| `create_new_window` | `default_open_behavior` | Result |
|---|---|---|
| `true` | Any value | Open a new window |
| `false` | Any value | Reuse the current window |
| Not specified | `"new_window"` | Open a new window |
| Not specified | `"existing_window"` | Reuse the current window |
## Root cause
The `from_existing_connection: true` action handler forwarded the
selected paths to `open_new_ssh_project_from_project` without reading
`action.create_new_window`.
That helper then called `open_remote_project` with:
```rust
OpenOptions {
workspace_matching: WorkspaceMatching::None,
..Default::default()
}
```
This left `OpenOptions::requesting_window` as `None`. The remote-opening
path interprets a missing requesting window as a request to create a new
window, so the action always opened one regardless of the action payload
or workspace setting.
## Solution
The existing-connection action handler now resolves `create_new_window`
before starting the asynchronous open operation.
When the action does not provide an explicit value, it uses the same
`WorkspaceSettings::default_open_behavior` fallback as the normal
project-opening path:
```rust
let create_new_window = action.create_new_window.unwrap_or_else(|| {
matches!(
WorkspaceSettings::get_global(cx).default_open_behavior,
DefaultOpenBehavior::NewWindow
)
});
```
The resolved boolean is passed to `open_new_ssh_project_from_project`.
The helper translates that policy into the existing `OpenOptions` API:
- When `create_new_window` is `true`, `requesting_window` remains
`None`.
- When it is `false`, `requesting_window` is set to the current
`MultiWorkspace` window handle.
The existing `WorkspaceMatching::None` behavior is intentionally
preserved. This PR changes only which OS window hosts the opened remote
workspace; it does not change workspace matching, path selection,
connection handling, telemetry, or error behavior.
### Why resolve the setting in the action handler?
The action handler is where the explicit action value and the workspace
setting are both available. Resolving the option there also matches the
neighboring local and remote project-opening flows.
Passing the resolved boolean keeps the helper’s input aligned with the
user-facing policy while allowing the helper to translate it into the
lower-level `requesting_window` representation.
### Why not change `open_remote_project`?
`open_remote_project` is shared by several remote-opening flows.
Inferring an active window inside that function would change the
semantics of unrelated callers that deliberately omit
`requesting_window` to create a new window.
Keeping the change in the existing-connection action path limits the
behavioral change to the reported issue.
### Dependency impact
The regression test needs a real mock remote workspace so that it
exercises the same action registration and remote-client checks as the
application.
The following test-support development dependencies were enabled for the
`zed` crate:
- `fs`, for `FakeFs`
- `remote`, for the mock `RemoteClient`
- `remote_server`, for `HeadlessProject`
These are development-only dependencies and do not change Zed’s runtime
dependency graph. The `Cargo.lock` change records `remote_server` as a
dependency of the `zed` package under the test configuration.
## Testing
Added an end-to-end GPUI regression test:
```text
test_open_remote_from_existing_connection_reuses_window
```
The test:
1. Creates a fake remote filesystem with two project directories.
2. Starts a headless mock remote server.
3. Opens the initial project through `open_remote_project`.
4. Verifies that exactly one window exists.
5. Transitions the mock client to `ServerNotRunning`.
6. Injects `/other-project` as the path-prompt result.
7. Dispatches:
```rust
zed_actions::OpenRemote {
from_existing_connection: true,
create_new_window: Some(false),
}
```
8. Verifies that the application still has exactly one window.
9. Answers the expected failed-reconnection prompt with `Cancel`,
allowing the detached action task to terminate cleanly.
The unavailable-server step keeps the test focused on window routing. It
avoids requiring a second successful mock SSH lifecycle while still
exercising the real action handler, path prompt, remote workspace,
helper, and `open_remote_project` entry point.
Before the production change, the test failed with:
```text
create_new_window: false should reuse the current window
left: 2
right: 1
```
After the change, the test passes.
### Verification performed
Focused regression test:
```sh
cargo test -p zed test_open_remote_from_existing_connection_reuses_window
```
Result:
```text
1 passed; 0 failed
```
GPUI scheduler sweep:
```sh
ITERATIONS=20 cargo test -q -p zed test_open_remote_from_existing_connection_reuses_window -- --nocapture
```
Result:
```text
Seeds 0 through 19 passed
```
Complete `zed` test target, run serially because several existing tests
share global session state:
```sh
cargo test -q -p zed -- --test-threads=1
```
Result:
```text
74 passed; 0 failed; 1 ignored
```
Formatting:
```sh
cargo fmt -p zed --check
```
Repository-prescribed Clippy check:
```sh
./script/clippy -p zed
```
This ran the release, all-targets, all-features configuration with
warnings denied and completed successfully.
The change and test were run on Fedora Linux.
### Manual verification
This can also be verified interactively:
1. Connect to a project over SSH.
2. Bind or dispatch:
```json
[
"projects::OpenRemote",
{
"from_existing_connection": true,
"create_new_window": false
}
]
```
3. Select another directory on the connected host.
4. Confirm that the project opens in the current Zed window.
5. Repeat with `create_new_window: true` and confirm that a new window
is created.
6. Omit `create_new_window` and confirm that the result follows
`default_open_behavior`.
No screenshot is included because this does not change rendered UI; it
changes which window contains the opened remote workspace.
## Scope and impact
- No unsafe code was added.
- No remote protocol or transport behavior changed.
- No settings schema changed.
- No action schema changed.
- No user-facing strings changed.
- No new runtime dependencies were introduced.
- The added work is limited to resolving one optional boolean and
downcasting the current window handle when reuse is requested.
- The window-handle lookup occurs only when this action is dispatched
and has no meaningful performance impact.
## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed opening a project from an existing remote connection to respect
the configured window behavior.
This PR reworks the extension card component to take care of most the
rendering.
It no longer implements `ParentElement` and instead takes care of
rendering the details of the card now. This also allows us to finally
render the list of features for dev extensions amongst some other
cleanup whilst working with these.
## Why this change?
This is in preparation for allowing to show extensions locally when the
fetch fails based on the information available. Currently, this would
require a lot of duplication and would be tedious to add. With this in,
we can much more easily just construct an extension card with the
upstream metadata missing, removing the need for duplication.
Lastly, this also adds a component preview for extensions cards so we
can play around more easily with other designs.
Release Notes:
- Installed dev extensions will now show the features they provide and
will also respect feature filters.
When the image viewer reloads an image after the underlying file
changes, it now tracks the `RenderImage` currently displayed by the view
and drops that image’s atlas entry before replacing it with a newly
decoded render image. This prevents rapidly updated images from
accumulating atlas textures per reload while keeping cleanup scoped to
the window that displayed the image.
Closes#35894
Release Notes:
- Fixed a memory leak when previewing images that are repeatedly updated
on disk.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Release Notes:
- copilot: Improve robustness of copilot chat provider by splitting
authorisation paths for edit predictions and chat. Note: Existing users
will have to re-authenticate with Copilot
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Fixes the bug that made us remove the sandbox.
The bug in question was very dumb:
- there is sophisticated machinery for detecting whether a user-granted
writable path is swapped out for a symlink in the timing gap between
approval and sandbox creation
- there was no equivalent machinery to do the same for the (much larger)
gap between a user *persisting an approval* (either for the current
thread or permanently via settings)
- The fix is essentially to store canonical (i.e. absolute and
symlink-free at all depths) paths as the source of truth, but retain the
raw path for display purposes
- On WSL, there is extra care needed becasue of the bidirectional
mounting (i.e. `/mnt/c/...` and `\\wsl.localhost\Ubuntu\...`). In
particular, `/mnt/c/...` paths, since their inodes do not necessarily
pin NTFS file references, weaken the sandbox guarantees, and so we need
some extra UI to call this out and docs etc...
This also does not remove the feature flag, but just toggles it to
"enabled_for_all"
---
Release Notes:
- N/A or Added/Fixed/Improved ...
---------
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: zed-zippy[bot] <234243425+zed-zippy[bot]@users.noreply.github.com>
Use `web_time::Instant` instead of `std::time::Instant` when advancing
scrollbar animations. This uses the web platform's compatible clock in
WASM builds.
Release Notes:
- N/A
# Objective
Enable the Project Panel Undo/Redo feature flag in all channels except
stable. This gives us control over when it lands in Stable, while also
allowing us to have it sit in Preview for longer than a single week, if
we want to.
## Solution
Update `ProjectPanelUndoRedoFeatureFlag::enabled_for_all` to be true on
all release channels except `ReleaseChannel::Stable`. The feature flag
doesn't allow us to scope it per environment so there's no way we could
enable the flag for all but only have it impact Preview, should have
added that safeguard in the beginning as stable is already relying on
the feature flag exclusively.
## Testing
N/A
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
---
Release Notes:
- N/A
# Objective
Fixes#59952.
Zed crash-loops on launch. The faulting thread aborts inside the Rust
standard library while closing a directory handle during background
worktree scanning: `std`'s `DirStream::drop`
(`library/std/src/sys/fs/unix.rs`) `assert!`s that `closedir()` succeeds
unless the error is `EINTR`. That handle originates in
`RealFs::read_dir`, which wraps `std::fs::read_dir(path)` in
`stream::iter(...)` and carries the live `ReadDir` across async
boundaries; the worktree `BackgroundScanner` (`scan_dir` →
`forcibly_load_paths`) later drops the stream. If `closedir()` returns a
non-`EINTR` error (e.g. `EBADF` under file-descriptor pressure — seen
alongside repeated `unable to start FSEvent stream` warnings on a large
dependency tree), `std` panics inside `Drop`. Zed's
`crashes::panic_hook` turns any panic into `process::abort()`, and
because the same workspace is re-scanned every launch, this is a
permanent crash loop. (`catch_unwind` can't help: the hook aborts before
unwinding.)
## Solution
Stop relying on `std`'s asserting close. Add a `read_dir_entries(path)`
helper that reads entries eagerly so the directory handle is opened and
closed within a single call:
- On unix, read via libc (`opendir`/`readdir`/`closedir`) and
**deliberately ignore a failing `closedir`**, so a close error degrades
gracefully instead of aborting the process.
- On non-unix, keep `std::fs::read_dir` (which has no such assert) but
collect eagerly so the handle is dropped within the call.
`RealFs::read_dir` now calls this helper. The change is scoped to
`crates/fs/src/fs.rs`; the watcher, scanner, and panic hook are
untouched.
## Testing
- Added unit tests in `crates/fs/src/fs.rs` for `read_dir_entries`:
entry listing, `.`/`..` exclusion, empty directories, and the
missing-directory error path.
- `cargo test -p fs read_dir` → 3 passed.
- `RUSTFLAGS="-D warnings" cargo build -p fs`, `cargo clippy -p fs
--all-features --all-targets -- -D warnings`, and `cargo fmt -p fs
--check` are all clean.
- Tested on macOS (aarch64). The `fs` crate compiles within the full
`cargo build -p zed` graph. I could not produce a running app binary in
my environment (the `gpui_macos` Metal step needs full Xcode, not just
Command Line Tools) — reviewers on a full Xcode setup can `cargo run -p
zed`.
- The original `closedir` `EBADF` is not deterministically reproducible,
so the fix is structural rather than verified against a live repro; the
tests guard the read path and behavior.
## 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 adheres to Zed's UI standards — N/A (no UI change)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
---
Release Notes:
- Fixed Zed crash-looping on launch when `closedir` fails during
background directory scanning
([#59952](https://github.com/zed-industries/zed/issues/59952)).
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Closes FR-133
`cosmic-text`'s BiDi line shaping machinery (`ShapeLine::new`) asserts
that every BiDi paragraph is following the same direction. It turns out
that our `gpui_wgpu` line shaping adapter would not account for that
leading to panics if text contained multiple BiDi paragraphs with
multiple directions. Not super common but worth fixing as the fix is not
super complicated. At the same time, I'd like to point out that there is
a patch submitted to `cosmic-text` that redoes shaping logic so that
this is no longer illegal:
https://github.com/pop-os/cosmic-text/pull/508 If it gets accepted, we
can revert this fix.
Release Notes:
- Fixed panic in `gpui_wgpu` if text contained multiple BiDi paragraphs
with mismatched directions.
# Objective
- The column filter popover was a static `ContextMenu`: no search, and
it didn't scale to columns with many unique values.
## Solution
- Replaced it with a `Picker<ColumnFilterDelegate>` with fuzzy search
and match highlighting over the column's unique values.
- Row order is frozen at open time (available first, then values hidden
by other filters under a "Hidden by other filters" header) so toggling a
value doesn't reshuffle the list.
- Added a footer with `{selected} / {total} rows selected` and "Clear
all".
- Added `fuzzy` and `picker` deps to `csv_preview`.
## Testing
- Search narrows to fuzzy matches with highlighting.
- Toggling a value updates its checkmark and footer count without
closing or reordering the list.
- Values excluded by another column's filter show disabled under "Hidden
by other filters".
- "Clear all" clears the column's filters and keeps the popover open.
## Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
## Showcase
| Before | After |
| --- | --- |
| <img width="660" height="351" alt="image"
src="https://github.com/user-attachments/assets/c78084a2-d327-4d48-9c05-f35383455713"
/> | <img width="660" height="354" alt="image"
src="https://github.com/user-attachments/assets/910d52ef-4530-4ac7-91ac-3db318cf6c19"
/> |
**+ search**
<img width="972" height="574" alt="image"
src="https://github.com/user-attachments/assets/1a26d0fc-c96c-4973-818d-7d053e8cce73"
/>
---
Release Notes:
- N/A
### Summary
This PR fixes three small bugs that could cause a multi-workspace's
reported location to be out of sync with its actual location, which
causes following to break in multiplayer collaboration sessions.
The first bug was that each child workspace's title bar within a
multi-workspace had its own `cx.observe_window_activation` subscription
that would set the associated child workspace's project location. This
caused problems because it ran for all child workspaces instead of just
the active workspace within the multi-workspace. The fix was moving
`cx.observe_window_activation` to the `cx.observe_new` call in the
`call` crate that tracks newly created windows/multi-workspaces.
The second bug was caused by an incorrect `if` statement in a
`MultiWorkspace` subscription that would return early if the window was
active and the event emitted by `MultiWorkspace` wasn't
`ActiveWorkspaceChanged`. This caused issues when the window was
inactive because it would incorrectly set the active call's location to
the wrong project. The fix was making the early return happen if the
window wasn't active.
The third bug was that every child `Workspace` also observed window
activation and called `update_active_view_for_followers`. This allowed
hidden workspaces to report their active view instead of only the active
workspace.
### Testing
I added a property test for bugs one/two and another prop test for bug 3
Release Notes:
- collab: Fix out of sync following bugs
This consolidates the proxy code in `client/src/proxy` into a new
`proxy_handshake` crate that implements the client side of HTTP CONNECT
and SOCKS4/4a/5/5h handshakes sans-IO: the protocol logic is a pure
state machine that never touches a socket, with thin drivers behind
`futures-io` and `tokio` feature flags. `client` now drives the
websocket's proxy tunnel through the tokio driver, and the `tokio-socks`
dependency goes away.
The main win is testability: the handshakes are now covered by
synchronous byte-level tests on both sides of each exchange, plus a
property test that the outcome is invariant under how the proxy's bytes
are chunked across reads — the class of partial-read bug that's hard to
hit with hand-written tests but easy to hit in production behind a
buffering proxy. The crate is written as if it were standalone (no
zed-internal dependencies, structured errors instead of `anyhow`), which
is also why it grows both driver flavors rather than just the one
`client` needs today.
Two deliberate behavior changes, both converging on spec/curl semantics:
- Proxy credentials embedded in URLs are now percent-decoded before use,
per RFC 3986 §3.2.1. Previously they were sent in their encoded form,
which only worked for credentials with no reserved characters. A
password that literally contains something like `%40` and relied on the
old behavior now needs the RFC-correct `%2540` spelling.
- `NO_PROXY` is now honored for the collaboration connection, matching
the exclusions reqwest already applies to the rest of Zed's HTTP
traffic.
TLS to the proxy itself (for `https://` proxy URLs) and DNS policy stay
in `client`, since those are I/O concerns the sans-IO crate deliberately
doesn't own.
Release Notes:
- Improved proxy support: the collaboration connection now respects
`NO_PROXY` and percent-encoded proxy credentials.
## Context
JSON rainbow bracket colors could shift across row chunk boundaries when
large ancestor objects were omitted by the bounded tree-sitter bracket
query window. This fixes the chunk-local depth reset by caching bracket
chunk data together with the active bracket stack after each chunk, then
using that inherited stack when later chunks are computed. For JSON
object braces that are too large for the bounded query, the
implementation recovers active ancestor `{...}` pairs from the syntax
tree so sibling object braces keep the same color even when jumping
directly to a later chunk.
Closes#50185
## How to Review
`crates/language/src/buffer/row_chunk.rs` adds indexed access to row
chunks so bracket cache computation can walk from the nearest cached
chunk up to the requested chunk.
`crates/language/src/buffer.rs` changes bracket range caching from
storing only per-chunk matches to storing per-chunk matches plus the
active bracket stack after that chunk. It preserves the existing bounded
query and greedy-match repair behavior, while adding JSON-specific
ancestor recovery for large object braces omitted by
`MAX_BYTES_TO_QUERY`.
`crates/language/src/buffer_tests.rs` adds a JSON regression fixture
that exceeds `MAX_BYTES_TO_QUERY`, fetches a later chunk before earlier
chunks, and verifies all same-depth sibling object braces keep the same
`color_index` across row chunks.
Video of manual test below :
[Screencast from 2026-07-10
08-09-30.webm](https://github.com/user-attachments/assets/fca6425b-b79c-4097-b4af-148db6aa23d9)
## Self-Review Checklist
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the UI/UX checklist
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed JSON rainbow bracket colors changing across row chunk
boundaries.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Allows you to click on the zoom percent to edit it. Right clicking the
percentage resets to 100%.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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:
- Added support for editing image viewer zoom levels directly from the
toolbar.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
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
Closes#42353
Release Notes:
- Fixed extension building failing on systems where Rust is installed
without rustup (e.g., NixOS, distro packages)
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Fixes what https://github.com/zed-industries/zed/pull/57748 does for
buffer search.
When project search is deployed with regex mode enabled and the query is
seeded from the editor's selection or the word under the cursor, that
text is literal, so regex chars in it (e.g. `.` in `z.d`) are now
escaped instead of being interpreted as regex syntax. This follows how
VSCode handles it.
Release Notes:
- Fixed project search queries seeded from the current selection being
interpreted as a regular expression instead of literal text when regex
mode was enabled.
Oleksandr Kholiavko