Fixes ZED-2D7

Release Notes:

- N/A *or* Added/Fixed/Improved ...

In an attempt to figure out what's wrong with `point_to_buffer_offset`
for crash https://github.com/zed-industries/zed/issues/40453. We want to
know which branch among these two is the bad one.

Release Notes:

- N/A

Co-authored-by: Lukas Wirth <lukas@zed.dev>

Closes #36223

Upsteam issue to track:
https://github.com/tailwindlabs/tailwindcss-intellisense/issues/1479

Release Notes:

- Fixed an issue where Zed hanged when editing certain Tailwind class
names.

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

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Co-authored-by: David Kleingeld <davidsk@zed.dev>

The `vim::visual::Vim.visual_block_motion` method was recently updated
(https://github.com/zed-industries/zed/pull/39355) in order to jump
between buffer rows instead of display rows. However, with this now
being the case, the `break` condition was never met when the motion was
horizontal rather than vertical and soft wrapped lines were used. As
such, this commit udpates the condition to ensure it's always reached,
preventing the hanging from happening.

Release Notes:

- Fixed hang in Vim's visual block motions when updating selections

---------

Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>

Release Notes:

- N/A

I noticed we had some typos that were getting through CI, but it looks
like the new version of `typos` catches them. So I updated it and fixed
them.

Release Notes:

- N/A

Adds a way to submit feedback about a zeta2 prediction from the
inspector. The telemetry event includes:
- project snapshot (git + unsaved buffer state)
- the full request and response
- user feedback kind and text 

Release Notes:

- N/A

I did not bump it for Linux as some machines have smaller disks (~300GB
or so); with Mac, we have at least 1TB on all of our boxes

Release Notes:

- N/A

Following a conversation with the maintainer/owner of
kotlin-language-server, he recommended switching to the official
language server, which is better in many aspects and also more actively
maintained.

Release Notes:

- Made the official Kotlin Language Server the default language server
for Kotlin.

This fixes an issue where we would search for the hovered diff hunk
based on the mouse hit test computed during (or prior) editor paint
instead of the mouse hit test computed prior to the mouse event
invocation.

That in turn could lead to cases where moving the mouse from the editor
to the project panel and then clicking a file shortly after would expand
a diff hunk when actually nothing should happen in that case.

Release Notes:

- Fixed an issue where diff hunks would sometimes erroneously toggle
upon mouse clicks.

Tests are hand-picked based on yours truly's preference

Release Notes:

- N/A

Having this in our logs with a timestamp should help when users submit
issues with logs about slow startup time.

Release Notes:

- N/A

For good backtraces in tests 'limited' is all we need.

Closes #ISSUE

Release Notes:

- N/A

I maintain this repository that contains several developer tools like
- ghostty
- zig
- yazi

all of them are updated usually the same day as upstream.

Release Notes: 

- N/A

Closes #ISSUE 

it is was still in
[discussion](https://github.com/zed-industries/zed/discussions/37983)

Release Notes:

- Added: `--reuse` (`-r`) CLI flag to replace the workspace in an
existing window instead of opening a new one

This PR adds a new `--reuse` (`-r`) CLI flag that allows users to
replace the workspace in an existing Zed window instead of opening a new
one or adding files to the current workspace.

### What it does

The `--reuse` flag finds an available local workspace window and
replaces its workspace with the newly specified paths. This provides a
third workspace opening mode alongside the existing `--add` and `--new`
flags.

### Implementation Details

- **CLI Flag**: Added `--reuse` (`-r`) flag with proper mutual exclusion
with `--add` and `--new`
- **Window Replacement**: Uses the existing `replace_window` option in
`workspace::OpenOptions`
- **Window Selection**: Reuses the first available local workspace
window
- **Fallback Behavior**: When no existing windows are found, creates a
new window
- **Test Coverage**: Added comprehensive test for the reuse
functionality

### Behavior

- `zed -r file.txt` - Replaces the workspace in an available window with
`file.txt`
- If no windows are open, creates a new window (same as default
behavior)
- Mutually exclusive with `-a/--add` and `-n/--new` flags
- Works with multiple files and directories

### Files Changed

- `crates/cli/src/cli.rs` - Added `reuse` field to `CliRequest::Open`
- `crates/cli/src/main.rs` - Added CLI argument definition and parsing
- `crates/zed/src/zed/open_listener.rs` - Implemented reuse logic and
added tests
- `crates/zed/src/zed/windows_only_instance.rs` - Updated for Windows
compatibility

### Testing

- ✅ Unit tests pass
- ✅ Manual testing confirms expected behavior:
  - Works when no windows are open
  - Replaces workspace in existing window
  - Maintains compatibility with existing `-a` and `-n` flags
  - Proper help text display


## Manual testing

#### In this first video we do a couple of tests: 

* **1**: What happens if we use the -r flag when there are no windows
open?
        - works as expected. It opens the files in a new window.
        
* **2**: Does it work as expected if there is already a window open.
Does it overrides the workspace?
- yes it does. When opening a different file it overrides the current
window instead of creating a new one.
        
* **3**: Does the -n flag still works as expected?
        - yes, it creates the project in a new window

* **4**: What about the -a flag?
       - yes, on the last accessed page 
       
* **5**: we do the replace command. It overrides the first opened
window, do we want this behavior?
- It is good enough that it overrides one of the opened windows with the
new project. It still makes the user automatically go to the window with
the specified files

* **6**: we use the -r command again replacing the workspace with a new
one.
       - this indeed worked as expected


https://github.com/user-attachments/assets/f1cd7f4b-f4af-4da2-a755-c0be7ce96c0d


#### In here the we check how the --help flag now displays the new
command. (Description was later updated)


https://github.com/user-attachments/assets/a8a7a288-d926-431b-a9f9-a8c3d909a2ec

Closes [#14093](https://github.com/zed-industries/zed/issues/14093)
Builds on [#32279](https://github.com/zed-industries/zed/pull/32279) by
making it theme dependent.
Discussion
[#37816](https://github.com/zed-industries/zed/discussions/37816)

Wraps the mode label indicator in a div and makes the wrapper and label
theme-able. Label weight to medium
Mode indicator will render like previously if not theme colors have been
set. (i.e., they match zed default- and fallbacks)
Really helps with visual confirmation of current mode.

_Did not investigate further if there is a way to keep the leading and
trailing -- if no theme var given._

Can be applied either by a theme itself or using `theme_overrides` in
settings.json

Theme colors applied via `theme_overrides`
<img width="233" height="34" alt="Screenshot 2025-10-08 at 23 01 08"
src="https://github.com/user-attachments/assets/a00d9ae4-b6db-46a0-84e2-98d2691a11ad"
/>
<img width="233" height="34" alt="Screenshot 2025-10-08 at 23 01 16"
src="https://github.com/user-attachments/assets/f27fddab-524d-43c4-9307-46b6a656cd35"
/>
<img width="233" height="34" alt="Screenshot 2025-10-08 at 23 01 23"
src="https://github.com/user-attachments/assets/7e477fff-7a40-4c01-95a7-fbd40fff6caa"
/>

No theme applied
<img width="233" height="34" alt="Screenshot 2025-10-08 at 23 01 31"
src="https://github.com/user-attachments/assets/8b7b2c75-007b-4074-a552-181c53f31213"
/>
<img width="233" height="34" alt="Screenshot 2025-10-08 at 23 01 36"
src="https://github.com/user-attachments/assets/7a708d81-2033-4d72-a844-57607a0434ea"
/>
<img width="233" height="34" alt="Screenshot 2025-10-08 at 23 01 40"
src="https://github.com/user-attachments/assets/526f9d10-4d0f-4bc5-af89-31fcca538ce4"
/>



https://github.com/user-attachments/assets/d0d71d4d-504f-4d18-bbd9-83d3a4b2adb7


Release Notes:

- Vim make mode indicator themeable

---------

Co-authored-by: willyHetland <willy.hetland@zeekit.no>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>

This feels a bit dangerous as long as we have the split releases problem

Release Notes:

- N/A

Closes #39901

I'm unsure as to which direction the team wants to go with this, but
this is the behavior of VSCode which is what this feature is based off
so i'm going with this.

Changes: 

1. Introduced a new argument to the `new` method on the Pane called
`ignore_max_tabs` that forces the `max_tabs` to None if it's true.
2. Added a new test `test_bypass_max_tabs_limit`.

Release Notes:

- Fixed: `max_tabs` Setting affecting the terminal pane.

---------

Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>

# Why

Refs:
*
https://github.com/zed-industries/zed/pull/39101#issuecomment-3350557981

# How

Apply suggested appearance changes in the comment mentioned above. I
have also retained the different background for header rows, since it
feels to me that it is something that GitHub styling lacks.

I have also attempted to shrink the table table element, to fit the
content width (so it does not span for the full width of preview), but I
have failed on those attempts. Tried to use many various GPUI
attributes, but only thing that worked was setting the exact width on
table container, also tried to reuse `max_lengths` values, but those are
counting characters, not the rendered width. I would like to explore
this a bit more, and try to follow up on those changes in a separate PR.

Release Notes:

- Improved table elements styling in Markdown Preview

# Preview

<img width="1616" height="582" alt="Screenshot 2025-09-30 at 12 04 30"
src="https://github.com/user-attachments/assets/4f1517cb-9046-4e09-a1e1-5223421efb71"
/>
<img width="1616" height="582" alt="Screenshot 2025-09-30 at 12 04 23"
src="https://github.com/user-attachments/assets/61303160-2b62-4213-80fc-ee8432cdf1fa"
/>
<img width="1616" height="582" alt="Screenshot 2025-09-30 at 12 04 15"
src="https://github.com/user-attachments/assets/059a447e-574d-4545-870a-93f1c00b3bb8"
/>
<img width="1616" height="582" alt="Screenshot 2025-09-30 at 12 04 42"
src="https://github.com/user-attachments/assets/8e7c6f9b-672f-4943-aded-1b644d2ff750"
/>
<img width="1616" height="582" alt="Screenshot 2025-09-30 at 12 04 34"
src="https://github.com/user-attachments/assets/6d31f7f3-d0ea-4987-bf8c-78f6b307a2b3"
/>

---------

Co-authored-by: Danilo Leal <daniloleal09@gmail.com>

This is needed for #38914 and seems generally useful to have for
contextual keybindings.

Release Notes:

- N/A

---------

Co-authored-by: David Kleingeld <davidsk@zed.dev>

Changes that I made:
- add "scrollbar.thumb.active_background" to all themes
- for dark themes: scrollbar.thumb.background is darker than hover (fg4
from palette for background and fg0 for hover)
- for light themes: scrollbar.thumb.background is lighter than hover
(fg4 for background and fg0 for hover like in dark theme case)

Those changes is consistent with VSCode gruvbox theme and other
applications.
For active_background I chose orange color, but we can use cyan color to
match vscode theme.

UPDATE: decided to use blue for active scrollbar as this color is used
as accent in other parts of gruvbox themes

Release Notes:

- Improved scrollbar colors for Gruvbox theme

---------

Co-authored-by: Danilo Leal <daniloleal09@gmail.com>

## 🎯 Description
Adds configurable window control buttons (minimize, maximize, close)
positioning for Linux, allowing users to choose between macOS-style
(left side) or Windows-style (right side) placement.

## ✨ Features
- New `title_bar.window_controls_position` setting with `"left"` and
`"right"` options
- Left positioning: macOS style (Close → Minimize → Maximize)
- Right positioning: Windows style (Minimize → Maximize → Close)
- Fixed transparent background issues for window controls
- Maintains consistent styling with Zed's theme

## 🔧 Technical Changes

### Settings System
- Added `WindowControlsPosition` enum in `settings_content.rs`
- Extended `TitleBarSettingsContent` with `window_controls_position`
field
- Updated `TitleBarSettings` to include the new configuration

### Title Bar Layout
- Modified `platform_title_bar.rs` to use setting for layout positioning
- Added conditional logic for `justify_start()` vs `justify_between()`
based on position
- Fixed transparent container background by adding `bg(titlebar_color)`

### Window Controls
- Updated `platform_linux.rs` to reorder buttons based on position
setting
- Changed button background from `ghost_element_background` to
`title_bar_background`
- Implemented proper button sequencing for both positions

## 🧪 How to Test
1. Add to your Zed settings:
   ```json
   {
     "title_bar": {
       "window_controls_position": "left"
     }
   }
   ```
   or
   ```json
   {
     "title_bar": {
       "window_controls_position": "right"
     }
   }
   ```
2. Restart Zed
3. Verify buttons are positioned correctly
4. Check that background is not transparent
5. Test button functionality (minimize, maximize, close)

## �� Expected Behavior
- **Left position**: Buttons appear on the left side of the title bar in
Close → Minimize → Maximize order
- **Right position**: Buttons appear on the right side of the title bar
in Minimize → Maximize → Close order
- **Background**: Solid background matching Zed's theme (no
transparency)

## 🔍 Files Changed
- `crates/settings/src/settings_content.rs` - Added enum and setting
- `crates/title_bar/src/title_bar_settings.rs` - Updated settings struct
- `crates/title_bar/src/platform_title_bar.rs` - Modified layout logic
- `crates/title_bar/src/platforms/platform_linux.rs` - Updated button
ordering and styling

## 🎨 Design Rationale
This feature provides Linux users with the flexibility to choose their
preferred window control button layout, improving the user experience by
allowing them to match their desktop environment's conventions or
personal preferences.

## ✅ Checklist
- [x] Code compiles without errors
- [x] Settings are properly serialized/deserialized
- [x] Background transparency issues resolved
- [x] Button ordering works correctly for both positions
- [x] Layout adapts properly based on configuration
- [x] No breaking changes to existing functionality

## 🔗 Related
This addresses the need for customizable window control positioning on
Linux, providing consistency with user expectations from different
desktop environments.


![demo2](https://github.com/user-attachments/assets/7333db34-d54e-427c-ac52-140925363f91)

Fixes #40742

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Co-authored-by: Danilo Leal <daniloleal09@gmail.com>

I have partially solved a problem caused by a structure in commit:
f7a0971d2b9c366338dabad13fb494fe0a2c83b1

Release Notes:

- N/A

Before:
<img width="723" height="480" alt="image"
src="https://github.com/user-attachments/assets/6600e0af-36cf-4aec-ace1-7ee4921e001e"
/>

After: 
<img width="764" height="217" alt="image"
src="https://github.com/user-attachments/assets/52111c27-c67a-4224-82bd-782cc6e07f97"
/>

Closes #40608

This fixes tabbing in both the settings ui nav bar and page content
going off screen instead of scrolling the focused element into a visible
view.

The bug occurred because `gpui::list` and `gpui::uniform_list` only
render visible elements, preventing non visible elements in a view from
having their focus handle added to the element tree. Thus making the tab
stop map skip over those elements because they weren't present.

The fix for this is scrolling to reveal non visible elements and then
focus the selected element on the next frame.

Release Notes:

- settings ui: Auto scroll to reveal items in navigation bar and window
when tabbing

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>

A cherry-pick of
https://github.com/zed-industries/zed/pull/40183/commits/f5188d55fbcbb3856038967bce8e824ddb42bdba

This fixes a hard-to-reproduce crash caused excerpts removal not
updating previous snapshot data after corresponding inlay data was
removed.
Same branch has a test:
https://github.com/zed-industries/zed/pull/40183/commits/8783a9eb4fbc60e3fbe0654c2d330bddfaa7ef0a
that does not fail on `main` due to different way inlays are queried, it
will be merged later.

Release Notes:

- N/A

Closes #5294

This PR adds a line ending indicator to the status bar, hidden by
default as discussed in
https://github.com/zed-industries/zed/issues/5294.

### Changes

- 8b063a22d8700bed9c93989b9e0f6a064b2e86cf add the indicator and
`status_bar.line_endings_button` setting.

- ~~9926237b709dd4e25ce58d558fd385d63b405f3b changes
`status_bar.line_endings_button` from a boolean to an enum:~~
  <details> <summary> show details </summary>

   - `always`     Always show line endings indicator.
- `non_native` Indicate when line endings do not match the current
platform.
   - `lf_only`    Indicate when using unix-style (LF) line endings only.
- `crlf_only` Indicate when using windows-style (CRLF) line endings
only.
   - `never`      Do not show line endings indicator.
   
I know this many options might be overdoing it, but I was torn between
the pleasant default of `non_native` and the simplicity of `lf_only` /
`crlf_only`.

My thinking was if one is developing on a project which exclusively uses
one line-ending style or the other, it would be nice to be able to
configure no-indicator-in-the-happy-case behavior regardless of the
platform zed is running on. But I'm not really familiar with any
projects that use exclusively CRLF line endings in practice. Is this a
scenario worth supporting or just something I dreamed up?

   </details>

- 01174191e4cf337069e7a31b0f0432ae94c52515 rename the action context for
`line ending: Toggle` -> `line ending selector: Toggle`.
When running the action in the command palette with the old name I felt
surprised to be greeted with an additional menu, with the new name it
feels more predictable (plus now it matches
`language_selector::Toggle`!)

### Future work

Hidden status bar items still get padding, creating inconsistent spacing
(and it kind of stands out where I placed the line-endings button):

<img alt="the gap after the indicator is larger than for other buttons"
src="https://github.com/user-attachments/assets/24a346d4-3ff6-4f7f-bd87-64d453c2441a"
/>

I started a new follow-up PR to address that:
https://github.com/zed-industries/zed/pull/39992

Release Notes:

- Added line ending indicator to the status bar (disabled by default;
enabled by setting `status_bar.line_endings_button` to `true`)

We very frequently move this in and out of the windows slot map on
`update_window_id` calls (and we call this a lot!). This alone showed up
as `memmove`s at roughly 1% perf in Instruments when scrolling a buffer
which makes sense, `Window` itself is 4kb in size. The fix is simple,
just box the `Window` instances, moving a pointer is cheap in
comparison.

Release Notes:

- N/A *or* Added/Fixed/Improved ...

I noticed that branch picker doesn't close until the checkout operation
is completed.
While normally it's not an issue, it becomes obvious if there are longer
running post checkout hooks. In that case selecting a branch makes it
feel like nothing has happened (there's a small indicator in the footer)
so it's possible to click it multiple times. Closing the modal before
the operation completes leads to the error modal saying `Failed to
change branch. entity released. Please try again.` even though the
checkout was successful.

The new behavior is to close the branch picker as soon as the branch is
selected. This also aligns with the existing behavior in `create_branch`
where `cx.emit(DismissEvent);` is called without waiting for
`repo.update`.
And as I mentioned before there an indicator in the footer saying `git
switch <branch_name>` with a spinner thingy.

I also added a check in the picker's `open` function where it first
checks if there's currently an active job and does not show the picker
in that case.

If this generally makes sense I can add the tests as well if needed.

P.S I checked how it works in VSCode and yes it also closes the branch
picker as soon as the branch is selected. The only difference is that
they show the loading indicator right next to the branch name (with a
new branch) but in our case the current branch and activity indicator
are located in different places.

<details><summary>Before</summary>


https://github.com/user-attachments/assets/adf08967-d908-45fa-b3f6-96f73d321262

</details>

<details><summary>After</summary>


https://github.com/user-attachments/assets/88c7ca41-7b39-42d6-a98b-3ad19da9317c

</details>

Release Notes:

- The branch picker now closes immediately after a branch is selected,
instead of waiting for the branch switch to complete.

Closes #39865

Release Notes:

- Fixed file finder display when searching for files in history if you
had several worktrees opened in a workspace. It now displays the
worktree root name to avoid confusion if you have several files with
same name in different worktrees.

---------

Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>

Closes #ISSUE

Adds a `Maybe<T>` type to `settings_content`, that makes the distinction
between `null` and omitted settings values explicit. This unlocks a few
more settings in the settings UI

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Closes #40683 

Release Notes:

- Changed jsonc files' icon

Closes #40267

Release Notes:

- Fixed a rare issue where the extension page would stutter while
scrolling.

We were dropping the entities once we created the buffers, so the weak
entities could never be upgraded. This treats new locations we see the
same as we would for a read/write call and stores the entity so that we
can follow like we normally would.

Release Notes:

- acp: Fix following not working with certain tool calls.

I love keybindings.

I spend way to much time thinking about them.

I also REALLY like working in Zed. 

so far, however, I have found the key context system in Zed to be less
flexible than in VSCode.
the HUGE context that is available in VSCode helps you create
keybindings for very specific targeted scenarios.

the tree like structure of the Zed key context means you loose some
information as focus moves throughout the application.
For example, it is not currently possible to create a keybinding in the
editor that will only work when one of the Docks is open, or if a
specific dock is open.

this would be useful in implementing solutions to ideas like #24222 
we already have an action for moving focus to the dock, and we have an
action for opening/closing the dock, but to my knowledge (very limited
lol) we cannot determine if that dock *is open* unless we are focused on
it.

I think it is possible to create a more flexible key binding system by
adding more context information to the higher up context ancestors.
while:
``` 
Workspace right_dock=GitPanel
    Dock
        GitPanel
            Editor
```
may seem redundant, it actually communicates fundamentally different
information than:
```
Workspace right_dock=GitPanel
    Pane
        Editor
```  

the first says "the GitPanel is in the right hand dock AND IT IS
FOCUSED",
while the second means "Focus is on the Editor, and the GitPanel just
happens to be open in the right hand dock"

This change adds a new set of identifiers to the `Workspace` key_context
that will indicate which docks are open and what is the specific panel
that is currently visible in that dock.

examples:
- `left_dock=ProjectPanel`
- `bottom_dock=TerminalPanel`
- `right_dock=GitPanel`

in my testing the following types of keybindings seem to be supported
with this change:
```jsonc
// match for any value of the identifier
"context": "Workspace && bottom_dock"
"context": "Workspace && !bottom_dock"
// match only a specific value to an identifier
"context": "Workspace && bottom_dock=TerminalPanel"
// match only in a child context if the ancestor workspace has the correct identifier
"context": "Workspace && !bottom_dock=DebugPanel > Editor"
```

some screen shots of the context matching in different circumstances:
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 20 34"
src="https://github.com/user-attachments/assets/116d0575-a1ae-4577-95b9-8415cda57e52"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 20 57"
src="https://github.com/user-attachments/assets/000fdbb6-80bd-46e9-b668-f4b54ab708d2"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 21 37"
src="https://github.com/user-attachments/assets/7b1c82da-b82f-4e14-a97c-3cd0e71bbca0"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 21 52"
src="https://github.com/user-attachments/assets/1fd4b65a-09f7-47a9-a9b7-fdce4252aec3"
/>
<img width="2032" height="1167" alt="Screenshot 2025-10-16 at 23 22 38"
src="https://github.com/user-attachments/assets/f4c2ac5c-e6f9-4e0e-b683-522b237e3328"
/>


the persistent_name values for `ProjectPanel` and `OutlinePanel` needed
to be updated to not have a space in them in order to pass the
`Identifier` check. all the other Panels already had names that did not
include spaces, so it just makes these conform with the other ones.

I think this is a great place to start with adding more context
identifiers and i think this type of additional information will make it
possible to create really dynamic keybindings!

Release Notes:

- Workspace key context now includes the state of the 3 docks

This PR adds a new action `editor::CollapseAllDiffHunks`
which will allow the user to choose any keybinding for hiding the
Expanded Diff Hunks.

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Reduces peak stack usage in these functions and should generally be a
bit performant.

Display map benchmark results
```
To tab point/to_tab_point/1024
                        time:   [531.40 ns 532.10 ns 532.97 ns]
                        change: [-2.1824% -2.0054% -1.8125%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high severe

To fold point/to_fold_point/1024
                        time:   [530.81 ns 531.30 ns 531.80 ns]
                        change: [-2.0295% -1.9054% -1.7716%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
  2 (2.00%) high mild
  1 (1.00%) high severe
```

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Closes #ISSUE

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Too small for release notes IMO

Release Notes:

- N/A

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Closes #40448

On Windows, PATH might be "Path" instead of "PATH"

Release Notes:

- N/A *or* Added/Fixed/Improved ...

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)

Release Notes:

- N/A

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>

The parameter label offsets are utf16 offsets, not utf8. Additionally we
now validate the language server output.

Closes https://github.com/zed-industries/zed/issues/40578

Companion bug on rust-analyzer side
https://github.com/rust-lang/rust-analyzer/pull/20876

Release Notes:

- Fixed `textDocument/signatureHelp` implementation not being LSP
compliant

Closes #40657

Release Notes:

- Added window controls to the settings window on Linux.

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>