Closes #ISSUE
More accurately map localhost to `127.0.0.1`. Previously we would
lowercase and simply replace all instances of localhost inside of the
URL string, meaning query parameters, username, password etc. could not
contain the string `localhost` or contain uppercase letters without
getting modified. Added a test ensuring the mapping logic works. The
previous implementation would fail this new test.
Release Notes:
- Improved the behavior of mapping `localhost` to `127.0.0.1` when
passing configured proxy urls to `node`
### Summary
This PR changes `gpui/build.rs` to look up the Windows SDK directory in
the registry instead of falling back to a hard-coded path.
---
### Problem
Currently, building `gpui` on Windows requires `fxc.exe` to be in `PATH`
or at a predefined location (unless `GPUI_FXC_PATH` is set). This
requires to maintain a certain build environment with proper paths/vars
or to install the specific SDK version.
It is possible to find the SDK automatically using the registry keys it
creates upon installation. Specifically in
`SOFTWARE\\WOW6432Node\\Microsoft\\Microsoft SDKs\\Windows\\v10.0`
branch there are:
* `InstallationFolder` telling the SDK installation location;
* `ProductVersion` telling the SDK version in use.
These keys provide enough information to locate the SDK binaries, with
added robustness:
* handles non-standard SDK installation path;
* deterministically selects the latest SDK when multiple versions are
present.
---
### Changes Made
* **Updated `crates/gpui/build.rs`**:
* added dependency on `winreg`
* introduced `find_latest_windows_sdk_binary()` helper
* updated fallback logic to use registry lookup
This PR only changes the fallback location, and does not touch the
established environment-based workflow.
Release Notes:
- N/A
---
### Impact
Reduces manual configuration needed to build GPUI on Windows.
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Closes#41457#41806#41801
Copilot started using `node:sqlite` module which is an experimental
feature between node v22-v23 (stable in v24). The fix was passing in the
experimental flag when Zed starts the copilot LSP.
I tested this with v20.19.5 and v24.11.0. The fix got v20.19 working and
didn't affect v24.11 which was already working.
Release Notes:
- AI: Fix Github Copilot edit predictions failing to start
Closes#41774
Release Notes:
- settings_ui: Fixed an integer underflow panic when attempting to hit
the `-` sign on settings item that take delays in milliseconds
`ICustomDestinationList::AppendCategory` rejects an empty `IObjectArray`
and returns an `E_INVALIDARG` error. Error propagated and caused an
early-return from `update_jump_list()`.
<img width="1628" height="540" alt="image"
src="https://github.com/user-attachments/assets/f8143297-c71e-42a1-a505-66cd77dfa599"
/>
Release Notes:
- N/A
- lsp: Fix dynamic registration of diagnostic capabilities not taking
effect when an initial capability is not specified
Gist of the issue lies within use of .get_mut instead of .entry. If we
had not created any dynamic capability beforehand, we'd miss a
registration, essentially
- **Determine whether to update remote caps in a smarter manner**
Release Notes:
- Fixed document diagnostics with Ty language server.
Closes#41533
Both of the issues in the release notes that are fixed in this PR, were
caused by incorrect usage of the `window.use_state` API.
The first issue was caused by calling `window.use_state` in a render
helper, resulting in the element ID used to share state being the same
across different pages, resulting in the state being re-used when it
should have been re-created. The fix for this was to move the
`window.state` (and rendering logic) into a `impl RenderOnce` component,
so that the IDs are resolved during the render, avoiding the state
conflicts.
The second issue is caused by using a `move` closure in the
`window.use_state` call, resulting in stale closure values when the
window state is re-used.
Release Notes:
- settings_ui: Fixed an issue where some dropdown menus would show
options from a different dropdown when clicked
- settings_ui: Fixed an issue where attempting to change a setting in a
dropdown back to it's original value after changing it would do nothing
This PR implements the `zeta-cli eval` command. It will:
- Run the edit prediction model if there are no cached results
- Compute precision/recall/F1 for context retrieval at the line level:
every retrieved line of context is counted as a true positive (correct
retrieval), false positive (retrieved something that was not expected),
or false negative (didn't retrieve an expected line)
- Compute similar metrics for edit predictions
- Pretty-print results, highlighting the difference between actual and
expected when printing to tty
Other changes:
- `zeta-cli predict` accepts a `--format` argument with options `md`,
`json`, `diff`
- Code restructure
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Agus Zubiaga <agus@zed.dev>
- Adds a new action `git::PullRebase` which adds `--rebase` in the final
command invoked by existing Git-Pull implementation.
- Includes the new action in "Fetch/Push" button in the Git Panel
(screenshot below)
- Adds key-binding for `git::PullRebase` in all three platforms,
following the existing key-binding patterns (`ctrl-g shift-down`)
- Update git docs to include the new action.
Sidenote: This is my first ever OSS contribution
Screenshot:
<img width="234" height="215" alt="image"
src="https://github.com/user-attachments/assets/713d068f-5ea5-444f-8d66-444ca65affc8"
/>
---
Release Notes:
- Git: Added `git: pull rebase` for running `git pull --rebase`.
If I understand this correctly: The `active_repo_id` uses
`get_or_insert_with`, which makes it dependent on the `RepositoryAdded`
event sequence. To ensure correct initialization of the `active_repo_id`
on the remote side, the first local `RepositoryAdded` event must
synchronously send an `UpdateRepository` to `updates_tx`.
Closes#30694
Release Notes:
- Fixed incorrect default repository selection when using remote
Update the `editor::Editor.handle_modifiers_changed` method to ensure
that the `editor::Editor.update_edit_prediction_preview` method is
called even if edit prediction preview is disabled, if there's an active
edit prediction preview.
Without this change it was possible for users to get into a state where
holding the modifiers to show the prediction were part of the modifiers
used to disable edit prediction. When that keybinding was used, edit
prediction would be disabled, but the edit prediction preview would
remain as active, so the context menu for the editor would never be
shown again, as the editor would assume it was still showing the edit
prediction preview.
Closes#40056
Release Notes:
- Fixed a bug that could cause the completions menu to stop being show
when edit predictions were disabled
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
## Add relative line numbers on wrapped lines, take 2
This is a rework of https://github.com/zed-industries/zed/pull/39268
that excludes
https://github.com/zed-industries/zed/pull/39268/commits/e7096d27a6463f6eb7c2a821637c5773b2460c10.
This commit introduced some line number rendering issues as described in
https://github.com/zed-industries/zed/issues/41422.
While @ConradIrwin suggested we try to pass in the buffer rows from the
calling method instead of the snapshot, that
appears to have had unintended consequences and I don't think the two
calculations were intended to do the same thing. Hence, this PR has
removed those changes.
This PR also includes the migration fix originally done by @MrSubidubi
in https://github.com/zed-industries/zed/pull/41351.
## Original PR description and release notes.
**Problem:** Current relative line numbering creates a mismatch with
vim-style navigation when soft wrap is enabled. Users must mentally
calculate whether target lines are wrapped segments or logical lines,
making `<n>j/k` navigation unreliable and cognitively demanding.
**How things work today:**
- Real line navigation (`j/k` moves by logical lines): Requires
determining if visible lines are wrapped segments before jumping. Can't
jump to wrapped lines directly.
- Display line navigation (`j/k` moves by display rows): Line numbers
don't correspond to actual row distances for multi-line jumps.
**Proposed solution:** Count and number each display line (including
wrapped segments) for relative numbering. This creates direct
visual-to-navigational correspondence, where the relative number shown
always matches the `<n>j/k` distance needed.
**Benefits:**
- Eliminates mental overhead of distinguishing wrapped vs. logical lines
- Makes relative line numbers consistently actionable regardless of wrap
state
- Preserves intuitive "what you see is what you navigate" principle
- Maintains vim workflow efficiency in narrow window scenarios
Also explained and discussed in
https://github.com/zed-industries/zed/discussions/25733.
Release Notes:
- Added support for counting wrapped lines as relative lines and for
displaying line numbers for wrapped segments. Changes
`relative_line_numbers` from a boolean to an enum: `enabled`,
`disabled`, or `wrapped`.
This PR adds the ability to configure which files are considered
"hidden" in the project panel and toggle their visibility with a
keyboard shortcut. Previously, the editor hardcoded dotfiles as hidden -
now users can customize the pattern and quickly show/hide them.
### Release Notes
- Added `project_panel::ToggleHideHidden` action with keyboard shortcuts
to toggle visibility of hidden files
- Added configurable `hidden_files` setting to customize which files are
marked as hidden (defaults to `**/.*` for dotfiles)
### Motivation
This change allows users to:
1. Quickly toggle hidden file visibility with a keyboard shortcut
2. Customize which files are considered "hidden" beyond just dotfiles
3. Better organize their project panel by hiding build artifacts, logs,
or other generated files
### Usage
**Toggle hidden files:**
- **macOS:** `cmd-alt-.`
- **Linux:** `ctrl-alt-.`
- **Windows:** `ctrl-alt-.`
**Customize patterns in settings:**
```json
{
"hidden_files": ["**/.*", "**/*.tmp", "**/build/**"]
}
```
### Changes
**Core Implementation:**
- Added `hidden_files` setting (defaults to `**/.*` to match current
dotfile behavior)
- Replaced hardcoded `name.starts_with('.')` logic with configurable
pattern matching using `PathMatcher`
- Hidden status propagates through directory hierarchies (if a directory
is hidden, all children inherit that status)
**User-Facing:**
- Added `ToggleHideHidden` action in the project panel
- Added keyboard shortcuts for all platforms
- Added settings UI entry for configuring `hidden_files` patterns
**Testing:**
- Added comprehensive test coverage validating default behavior, custom
patterns, propagation, and settings changes
### Implementation Notes
- Uses `PathMatcher` for efficient glob matching
- Settings changes automatically trigger worktree re-indexing
- No breaking changes - defaults maintain current behavior (hiding
dotfiles)
---
**Disclaimer:** This was implemented with a fair amount of copy/paste
(particularly the gitignore handling), trial and error, and a healthy
dose of Claude.
### Screenshots
**Project Panel with hidden files visible:**
<img width="1368" height="935" alt="Screenshot 2025-10-30 at 3 15 53 AM"
src="https://github.com/user-attachments/assets/1cbe90ce-504c-4f9b-bca8-bef02ab961be"
/>
**Project Panel with hidden files hidden:**
<img width="1363" height="917" alt="Screenshot 2025-10-30 at 3 16 07 AM"
src="https://github.com/user-attachments/assets/9297f43e-98c7-4b19-be8f-3934589d6451"
/>
**Toggle action in command palette:**
<img width="565" height="161" alt="Screenshot 2025-10-30 at 3 17 26 AM"
src="https://github.com/user-attachments/assets/4dc9e7b6-9c29-4972-b886-88d8018905da"
/>
Release Notes:
- Added the ability to configure glob patterns for files treated as
hidden in the project panel using the `hidden_files` setting.
- Added an action `project panel: toggle hidden files` to quickly show
or hide hidden files in the project panel.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#39037
Previously, the code split the `**/.env` glob in `file_scan_inclusions`
into two sources for the `PathMatcher`: `["**", "**/.env"]`. This
approach works for directories, but including `**` will match all
directories and their files. To address this, I now select the
appropriate `PathMatcher` using only `**/.env` when specifically
targeting a file to determine whether to include it in the file finder.
Release Notes:
- Fixed: respect `.gitignore` and `file_scan_inclusions` settings with
`**` in glob for file finder
---------
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Julia Ryan <juliaryan3.14@gmail.com>
- Update `vim::object::find_mini_delimiters` in order to filter out the
ranges before calling `vim::object::cover_or_next`, ensuring that the
provided ranges are converted from multibuffer space into buffer
space.
- Remove the `range_filter` from `vim::object::cover_or_next` was the
`find_mini_delimiters` function is the only caller and no longer uses
it
Closes#41346
Release Notes:
- Fixed a crash that could occur when using `vim::MiniQuotes` and
`vim::MiniBrackets` in a multibuffer
Prior to this change we would always resolve envs when spawning a new
terminal window based on the inherited CLI environment. This works fine
as long as we open a new Zed instance in the terminal when using it
locally only. When using Zed connected to a remote server, it would not
be meaningful however. WIth this change, we correctly ping the remote
for the project-local envs and use that instead. This change should also
fix a pesky issue when updating Zed - after Zed restarts, opening a new
terminal window will not run `direnv` for example.
Release Notes:
- N/A
Related discussions #26084
Worktree creations are implemented similar to how branch creations are
handled on the branch picker (the user types a new name that's not on
the list and a new entry option appears to create a new branch with that
name).
https://github.com/user-attachments/assets/39e58983-740c-4a91-be88-57ef95aed85b
With this picker you have a few workflows:
- Open the picker and type the name of a branch that's checked out on an
existing worktree:
- Press enter to open the worktree on a new window
- Press ctrl-enter to open the worktree and replace the current window
- Open the picker and type the name of a new branch or an existing one
that's not checked out in another worktree:
- Press enter to create the worktree and open in a new window. If the
branch doesn't exists, we will create a new one based on the branch you
have currently checked out. If the branch does exists then we create a
worktree with that branch checked out.
- Press ctrl-enter to do everything on the previous point but instead,
replace the current window with the new worktre.
- Open the picker and type the name of a new branch or an existing one
that's not checked out in another worktree:
- If a default branch is detected on the repo, you can create a new
worktree based on that branch by pressing ctrl-enter or
ctrl-shift-enter. The first one will open a new window and the last one
will replace the current one.
Note: If you preffer to not use the system prompt for choosing a
directory, you can set `"use_system_path_prompts": false` in zed
settings.
Release Notes:
- Added git worktree picker to open a git worktree on a new window or
replace the current one
- Added git worktree creation action
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Making the profile management modal accessible through the agent panel
additional options menu as well. And in the process, adjusting the menu
keybinding that was getting conflicted with something else.
Release Notes:
- N/A
This PR makes the agent panel's configuration view use the icon from an
external agent that comes directly from the extension, as well as some
other clean ups.
Release Notes:
- N/A
We see `test_extension_store_with_test_extension` hang in untarring the
WASI SDK some times.
In lieu of trying to debug the problem, let's try shelling out for now
in the hope that the test becomes more reliable.
There's a bit of risk here because we're using async-tar for other
things (but probably not 300Mb tar files...)
Assisted-By: Zed AI
Closes #ISSUE
Release Notes:
- N/A
This PR adds a `zeta zeta2 predict` subcommand that takes an edit
prediction example markdown file as an argument, and performs zeta2's
prediction, showing the retrieved context and the predicted edit.
* [x] Apply uncommitted diff to get repo into the right state.
* [x] Apply edits in edit history
* [x] Display predicted edits as unified diff, regardless of model
output format
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Ben Kunkle <ben.kunkle@gmail.com>
A user on Discord requested this feature:
https://discord.com/channels/869392257814519848/1434188637389717556/1434188637389717556
I added a scrollbar setting called `completion_menu_scrollbar` to the
completion menu and defaulted it to "Never" to match past behavior.
Release Notes:
- editor: Add `editor.completion_menu_scrollbar` setting to show a
scrollbar in the completion menu
Closes #ISSUE: reported on X by user.
Release Notes:
- Made it so that the default value for the "remove trailing whitespace
on save" setting in Markdown is false, to fix cases where the removed
trailing whitespace had syntactic meaning
Conrad Irwin