Continues the work from #35927 to add a git diff view for stash entries.
[Screencast From 2025-09-17
19-46-01.webm](https://github.com/user-attachments/assets/ded33782-adef-4696-8e34-3665911c09c7)
Stash entries are [represented as
commits](https://git-scm.com/docs/git-stash#_discussion) except they
have up to 3 parents:
```
.----W (this is the stash entry)
/ /|
-----H----I |
\|
U
```
Where `H` is the `HEAD` commit, `I` is a commit that records the state
of the index, and `U` is another commit that records untracked files
(when using `git stash -u`).
Given this, I modified the existing commit view struct to allow loading
stash and commits entries with git sha identifier so that we can get a
similar git diff view for both of them.
The stash diff is generated by comparing the stash commit with its
parent (`<commit>^` or `H` in the diagram) which generates the same diff
as doing `git stash show -p <stash entry>`. This *can* be
counter-intuitive since a user may expect the comparison to be made
between the stash commit and the current commit (`HEAD`), but given that
the default behavior in git cli is to compare with the stash parent, I
went for that approach.
Hoping to get some feedback from a Zed team member to see if they agree
with this approach.
Release Notes:
- Add git diff view for stash entries
- Add toolbar on git diff view for stash entries
- Prompt before executing a destructive stash action on diff view
- Fix commit view for merge commits (see #38289)
Add new `workspace::NewFileSplit` action which expects a
`SplitDirection` argument, allowing users to programmatically control
the direction of the split in keymaps, for example:
```json
{
"context": "Editor",
"bindings": {
"ctrl-s ctrl-h": ["workspace::NewFileSplit", "left"],
"ctrl-s ctrl-j": ["workspace::NewFileSplit", "down"],
"ctrl-s ctrl-k": ["workspace::NewFileSplit", "up"],
"ctrl-s ctrl-l": ["workspace::NewFileSplit", "right"]
}
}
```
Release Notes:
- Added `workspace::NewFileSplit` action, which can be used to
programmatically split the editor in the provided direction.
Co-authored-by: Rian Drake <rian.drake@rocketwerkz.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
This is an in-progress work on changing how task scheduler affects
performance of project search. Instead of relying on tasks being
executed at a discretion of the task scheduler, we want to experiment
with having a set of "agents" that prioritize driving in-progress
project search matches to completion over pushing the whole thing to
completion. This should hopefully significantly improve throughput &
latency of project search.
Release Notes:
- Improved project search performance
---------
Co-authored-by: Smit Barmase <smit@zed.dev>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Release Notes:
- Added comment language injections for builtin languages. This enables
highlighting of `TODO`s and similar notes with the comment extension
installed.
Signed-off-by: Donnie Adams <donnie@thedadams.com>
Related to #9461, inspired by #39683
`await` and `yield` both seem somewhat debatable on whether they should
be considered the be control flow keywords.
For now I went with:
- `await`: no – The control flow effect of `await` is at a level does
not seem relevant for syntax highlighting.
- `yield`: yes – `yield` directly affects the output of a generator, and
is also included for consistency with Rust (#39683).
Happy to change these either direction.
<img width="1151" height="730" alt="SCR-20251008-izus"
src="https://github.com/user-attachments/assets/533ea670-863a-4c5c-aaa5-4a9bfa0bf0dd"
/>
---
Release Notes:
- Improved granularity of keyword highlighting for JS/TS/TSX: Themes can
now specify `keyword.control` for control flow keywords like `if`,
`else`, `return`, etc.
- Notable change is the use of a newtype for `ReplicaId`
- Fixes `WorktreeStore::create_remote_worktree` creating a remote
worktree with the local replica id, though this is not currently used
- Fixes observing the `Agent` (that is following the agent) causing
global clocks to allocate 65535 elements
- Shrinks the size of `Global` a bit. In a local or non-collab remote
session it won't ever allocate still.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Let's say you run this:
```
cd ~/proj-a
zed ~/proj-b
```
The `zed` process will execute with `current_dir() = ~/proj-a`, but a
`worktree_root_path() = ~/proj-b`. The old detection was then checking
if the Yarn SDK was installed in `proj-a` to decide whether to set the
tsdk value or not. This was incorrect, as we should instead check for
the SDK presence inside `proj-b`.
Release Notes:
- Fixed the Yarn SDK detection when the Zed pwd is different from the
opened folder.
# Why
While working on recent PR I have spotted that "Stage" and "Unstage"
buttons in "Uncommited Changes" toolbar are always active, even when
there is no changes made locally.
<img width="1628" height="656" alt="Screenshot 2025-10-10 at 00 49 06"
src="https://github.com/user-attachments/assets/6bdb9ded-17c8-4f84-8649-b297162c1992"
/>
# How
Re-use already existing button states for managing the disabled state of
"Uncommited Changes" toolbar buttons when changeset is empty.
Release Notes:
- Added disabled state for "Uncommited Changes" toolbar buttons when
there are no changes present
# Preview
<img width="1728" height="772" alt="Screenshot 2025-10-10 at 08 40 14"
src="https://github.com/user-attachments/assets/ff41d852-974e-4ce1-9163-ecd30e17d5d8"
/>
Closes#37322
Uses SFTP if available, otherwise falls back to SCP for uploading files
and directories to remote. This fixes an issue on older macOS versions
where outdated SCP can throw an ambiguous target error.
Release Notes:
- Fixed an issue where extensions wouldn’t work when SSHing into a
remote from older macOS versions.
Refactor the find_tab_group method to use the question mark operator for
cleaner error handling, replacing the explicit if-else pattern with a
more concise chained approach.
Release Notes:
- N/A
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
### Problem
On Windows, the right Alt key was not working in keybindings (e.g.,
`Ctrl+Right Alt+B`), while the left Alt key worked correctly. This was
due to overly aggressive AltGr detection that treated any `right Alt +
left Ctrl` combination as AltGr, even on US keyboards where AltGr
doesn't exist.
### Root Cause
Windows internally represents AltGr (Alt Graph) as `right Alt + left
Ctrl` pressed simultaneously. The previous implementation always
excluded this combination from being treated as regular modifier keys to
support international keyboards. However, this broke keybindings using
right Alt on US/UK keyboards where users expect right Alt to behave
identically to left Alt.
### Solution
Implemented keyboard layout-aware AltGr detection:
1. Added `uses_altgr()` method to `WindowsKeyboardLayout` that checks if
the current keyboard layout is known to use AltGr (German, French,
Spanish, Polish, etc.)
2. Modified `current_modifiers()` to only apply AltGr special handling
when the keyboard layout actually uses it
3. Added explicit checking for both `VK_LMENU` and `VK_RMENU` instead of
relying solely on the generic `VK_MENU`
### Behavior
- **US/UK keyboards**: Right Alt now works identically to left Alt in
keybindings. `Ctrl+Right Alt+B` triggers the same action as `Ctrl+Left
Alt+B`
- **International keyboards** (German, French, Spanish, etc.): AltGr
continues to work correctly for typing special characters and doesn't
trigger keybindings
- **All keyboards**: Both Alt keys are detected symmetrically, matching
the behavior of left/right Windows keys
### Testing
Manually tested on Windows with US keyboard layout:
- `Ctrl+Left Alt+B` triggers keybinding
- `Ctrl+Right Alt+B` triggers keybinding
- Both Alt keys work independently in keybindings
Release Notes:
- Fixed Right Alt key not working in keybindings on Windows
Release Notes:
- Fixed misplaced comma in the autoclose description from:
"when you type (, Zed will ...)"
to
"when you type, (Zed will ...)"
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
`env_logger` defaults to only showing error-level logs, but we show
info-level logs and above for the main Zed process, so I think it makes
sense for the remote server to behave the same way.
Release Notes:
- N/A
Re-applies https://github.com/zed-industries/zed/pull/30840
This PR re-applies the initial
[PR](https://github.com/zed-industries/zed/pull/30840). As it was closed
because it was hard to land, because of the many conflicts. This PR
re-applies the changes for it.
In several cases we were creating multiple display_map
snapshots within the same root-level function call.
Creating a display_map snapshot is quite slow, and in some
cases we were creating the snapshot multiple times.
Release Notes:
- N/A
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
A small follow-up to the settings refactor of a few weeks ago to move
all the VSCode settings imports
to one place.
This should make it easier to spot missing imports, and easier to test
the importer.
Release Notes:
- N/A
It is now possible to configure logging level of CodeLLDB adapter via
envs specified in project settings like so:
```
{
"dap": {
"CodeLLDB": {
"envs": {
"RUST_LOG": "debug"
}
}
}
}
```
Release Notes:
- N/A
Alvaro Parker