[pull] main from zed-industries:main#804
Merged
pull[bot] merged 14 commits intoesinanturan:mainfrom Oct 21, 2025
Merged
Conversation
…40415) 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>
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.
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 ...
Closes #5294 This PR adds a line ending indicator to the status bar, hidden by default as discussed in #5294. ### Changes - 8b063a2 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> - 0117419 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: #39992 Release Notes: - Added line ending indicator to the status bar (disabled by default; enabled by setting `status_bar.line_endings_button` to `true`)
A cherry-pick of f5188d5 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: 8783a9e that does not fail on `main` due to different way inlays are queried, it will be merged later. Release Notes: - N/A
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>
…nflict (#40745) I have partially solved a problem caused by a structure in commit: f7a0971 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" />
Fixes #40742 Release Notes: - N/A *or* Added/Fixed/Improved ... 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.
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>
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>
# Why Refs: * #39101 (comment) # 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>
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>
This feels a bit dangerous as long as we have the split releases problem Release Notes: - N/A
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )