## 🎯 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>

Release Notes:

- N/A

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.

Adding this content after seeing people ask about how to make MCP
servers installed from Zed be picked up by external agents. At the
moment, this varies depending on the agent, and felt relevant to be
documented.

Release Notes:

- N/A

Fixed: #40039
Fixed: #40404
Fixed: #40272
Fixed: #40666

Release Notes:

- N/A

This allows us to play with IDs < 8 without having to do another
redeploy

Release Notes:

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

Release Notes:

- N/A

part of https://github.com/zed-industries/zed/issues/9461


Release Notes:
- Added the ability to seperately highlight control flow keywords for
Rust, C and C++ for users and theme authors via the `keyword.control`
syntax property
<img width="805" height="475" alt="スクリーンショット 2025-10-07 22 21 59"
src="https://github.com/user-attachments/assets/40ed03ea-a129-44ce-b6d8-284656b9f3ba"
/>

- 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 ...

It was erroenously removed in #40216

Release Notes:

- N/A

Added more granular symbols for ts and js in outline panel. This is a
bit closer to what vscode offers.

<details><summary>Screenshots of current vs new</summary>
<p>
New:
<img width="1723" height="1221" alt="image"
src="https://github.com/user-attachments/assets/796d3b59-fffa-4a66-9986-f7c75e618103"
/>

Current:
<img width="1714" height="1347" alt="image"
src="https://github.com/user-attachments/assets/f7cff463-de2a-4d86-b1a6-e19f4fd8dc6e"
/>

Current vscode (cursor):
<img width="1710" height="1177" alt="image"
src="https://github.com/user-attachments/assets/31902d52-becf-4d3f-960d-7e054e00e32d"
/>

</p>
</details> 

I have never touched scheme before, and pair-programmed this with ai, so
please let me know if there's any glaring issues with the
implementation. I just miss the outline panel in vscode very much, and
would love to see this land.
Happy to help with tsx/jsx as well if this is the direction you guys
were thinking of taking the outline impl.

Doesn't fully close https://github.com/zed-industries/zed/issues/20964
as there is no support for chained class method callbacks or
`Class.prototype.method = ...` as mentioned in
https://github.com/zed-industries/zed/issues/21243, but this is a step
forward.

Release Notes:

- Improved typescript and javascript symbol outline panel

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.

The page about PHP in the docs doesn’t explain how to use Xdebug. I had
a lof of trouble setting it up the first time, then recently had another
headache trying to get it to work again, because the value for `adapter`
had changed from `PHP` to `Xdebug`.

It’s likely that my example config isn’t perfect or has redundant stuff
or whatever, feel free to amend it.

I also took the liberty to set the Phpactor and Intelephense headings to
level 3 because I felt like they were part of "Choosing a language
server."

Release Notes:

- N/A

Closes https://github.com/zed-extensions/vue/issues/48

Migration guide:
https://github.com/vuejs/language-tools/discussions/5456

PR to remove tdsk: https://github.com/zed-extensions/vue/pull/61

Release Notes:

- Added support for Vue language server version 3. Know more
[here](https://github.com/vuejs/language-tools/releases/tag/v3.0.0).

---------

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

Closes #40610

Release Notes:

- N/A

# 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"
/>

Release Notes:

- N/A

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.

This setting is unused (we always stream edits)

Release Notes:

- N/A

Release Notes:

- Fixed worktree names not updating when renaming the root folder on
windows

Release Notes:

- N/A

---------

Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>

Release Notes:

- N/A

Co-authored-by: Piotr piotr@zed.dev
Co-authored-by: Lukas lukas@zed.dev
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Co-authored-by: Gaauwe Rombouts <mail@grombouts.nl>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>