ac94de78ab696fc897b82de467490c1a57e72a6d
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Ben Kunkle
|
aecaacdb44 |
git: Move diff hunk operations onto buffer diffs (#63556)
# Objective Keep Git-specific diff-base knowledge in `GitStore`, where Git operations are defined. Related to FR-135. ## Solution Give each `BufferDiff` its supported hunk operations. Keep editor hooks limited to rendering custom controls. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - N/A |
||
|
Miguel Raz Guzmán Macedo
|
513ad12cef |
Avoid redundant string allocations (#63377)
Remove unnecessary intermediate `String` allocations when constructing `Arc<str>` and `SharedString` values. Use static `SharedString` storage for fixed worktree picker identifiers. Validation: - `cargo fmt --all -- --check` - `tooling/lints/single-lint owned_string_into_shared -p editor -p git_ui_core -p toolchain_selector` - `cargo test -p editor -p git_ui_core -p toolchain_selector` Release Notes: - N/A |
||
|
Smit Barmase
|
3122f37ff1 |
git_ui_core: Fix worktree creation for bare repositories (#63351)
Follow-up https://github.com/zed-industries/zed/pull/55153 Fixes https://github.com/zed-industries/zed/discussions/54553#discussioncomment-17091833 When a repository stores its Git data in `~/work/zed/.bare`, creating a linked worktree from Zed is broken in two visible ways: - Zed creates `random-code` at: ``` ~/work/worktrees/.bare/random-code/.bare ``` instead of: ``` ~/work/worktrees/zed/random-code/zed ``` - Because the checkout ends in `.bare`, Zed displays `.bare` as its worktree name in the title bar, worktree picker, and agent thread sidebar. Every worktree Zed creates from that repository gets the same `.bare` label instead of its generated name. This problem is specific to the path Zed creates. Worktrees using either of these layouts are not malformed: ``` ~/work/worktrees/zed/random-code/zed ~/work/zed/some-worktree ``` https://github.com/zed-industries/zed/pull/55153 introduced repository identities for bare repositories. This PR uses that identity in the remaining worktree naming and creation paths. There are three repository layouts to account for: - In a normal repository, the common Git directory is `~/work/zed/.git`, so Zed derives the main worktree at `~/work/zed`. Existing behavior remains unchanged. - With `~/work/zed/.bare`, Git has no main worktree. A checkout named main is still a linked worktree. Zed now treats `~/work/zed` as the repository identity, creates new worktrees under `~/work/worktrees/zed`, and displays their generated names. - With a bare repository named `~/work/foo.git`, `foo.git` is the repository identity. Its worktree path remains `~/work/worktrees/foo.git/random-code/foo.git`. Zed uses foo.git to derive the worktree name random-code, while displaying the repository itself as foo. Existing malformed worktrees such as `~/work/worktrees/.bare/random-code/.bare` are not moved and may continue to display `.bare`. Broken: <p> <img width="238" height="58" alt="image" src="https://github.com/user-attachments/assets/1504e4d0-c34a-471f-8e76-c5ec062b1d77" /> </p> <p> <img width="274" height="49" alt="image" src="https://github.com/user-attachments/assets/13266ca9-4e64-426c-b03c-e23c924a3597" /> </p> <p> <img width="574" height="85" alt="image" src="https://github.com/user-attachments/assets/0fca58c7-5be7-4d36-9067-066d0b80caf8" /> </p> Release Notes: - Fixed linked worktree names and creation paths for bare Git repositories. |
||
|
Enzo GAZZOLIandKirill Bulatov
|
1155a5becd |
Render control characters in tab titles and project panel entries (#62875)
# Objective Fixes #62664 File names may contain control characters (`\n`, `\r`, `\t`, …) on most platforms. Zed rendered them verbatim, so a file named `notes\ndraft.md` broke the layout of its tab and of its project panel entry instead of showing a readable name. The same held anywhere else a name reached the screen without going through `Label::single_line`. ## Solution The substitution lives in one shared place, `ui::utils::replace_control_characters`, reached through `Label::single_line`. `\n` keeps rendering as the `⏎` Zed already used, so nothing that renders correctly today changes; every other C0 control character maps onto the Unicode "Control Pictures" block by a single rule (`U+2400 + code point`), giving `␉` for tab and `␍` for carriage return. `DEL` maps to `␡`. C1 controls are left alone, having no equivalent there. Where that is wired in: - **`Label::single_line`** — replaces its previous `\n`-only substitution. The project panel already used it everywhere, including folded directory components, so the panel is fixed by this alone. - **Editor tabs** and the **default `Item::tab_content`**, neither of which called `single_line`. - **Terminal tab titles**, which render through their own `tab_content`. Those titles come from OSC escape sequences, so the control characters in them are attacker-controlled. - **`HighlightedLabel::single_line`**, which never substituted anything — not even `\n`. See below. - **The file finder**, for both the file name and the path. - **Nine `tab_content` overrides in git_ui**, by deleting them. - **`HighlightedMatchWithPaths`**, for both the match label and its paths — it backs the tab switcher and the outline panel, among others. ### `HighlightedLabel` needs its offsets moved, not just its text Its highlight indices are byte offsets, and every stand-in is wider in bytes than the character it replaces, so the offsets have to move with the text. Left alone they index into the middle of a character, and `highlight_ranges` slices the string at exactly those offsets — which panics in release builds too. The constructor's `debug_panic!` does not cover this, since `single_line` runs after construction. So `replace_control_characters_remapping_offsets` substitutes and remaps in one pass, over an old-to-new byte offset table built the way `ensure_uniform_list_compatible_label` does it in `lsp_store`. This also fixes the call sites that already asked for a single line, including the branch picker and the tabular column filter values. ### Deleting the git_ui overrides Nine files replicated the default `Item::tab_content` verbatim except for the colour, hardcoding `selected ? Default : Muted` instead of `params.text_color()`. Deleting them lets those tabs inherit the fixed default, and fixes a second bug along the way: none of them dimmed when the pane lost focus. Titles and icons are unaffected — they come from `tab_content_text` and `tab_icon`, which the default calls. `git_graph.rs` already did it this way. ### Tabular column headers These never went through a `Label` at all: the raw `SharedString` was a child of a `div`. They now display stand-ins, while right-click-copy still yields the real column name. Two notes for reviewers: - Both helpers avoid allocating when there is nothing to replace, so the common path is untouched. The previous `self.label.replace('\n', "⏎")` allocated a `String` on every render for every label — including every visible project panel entry, every frame. - Every stand-in is exactly one character, so character offsets are preserved and the existing `truncate_and_trailoff` math on tab titles stays correct. ## Testing - Unit tests cover both helpers: each control character's substitution, repeated occurrences, multi-byte characters (accents, emoji), the borrow-vs-own behaviour, the preserved character count, C1 passthrough, and — for the remapping — offsets before, at and after a replacement, offsets at and past the end, and the invariant that every remapped offset lands on a character boundary. - Unit tests cover `Label::single_line` and `HighlightedLabel::single_line`, the entry points every call site uses. `highlighted_label.rs` had no tests before. - `cargo test -p ui -p file_finder -p workspace -p project_panel -p git_ui -p git_ui_core -p terminal_view -p tabular_data_preview` passes (774 tests), as do `cargo clippy` and `cargo fmt --check`. - No existing test changes behaviour: tests assert on `tab_content_text`, which is untouched; only rendering paths changed. - Verified manually on macOS (aarch64) — see Showcase. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments — none added - [x] The content adheres to Zed's UI standards - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable ## Showcase A directory holding `report<TAB>table.csv`, `notes<LF>draft.md`, `carriage<CR>return.txt` and a normally named `normal.txt`, all four open as tabs. **Before**  **After**  Three things change: 1. **The `notes<LF>draft.md` tab** is the clearest one. Before, the literal newline splits the tab across two lines — `notes` above `draft.md` — distorting the whole tab bar. After, it stays on one line. 2. **`carriage<CR>return.txt` in the project panel** renders as `carriagereturn.txt` before: the `\r` is completely invisible, so the name reads as one word and there is no way to tell a character is there. After, it renders as `carriage␍return.txt`. 3. **`report<TAB>table.csv`** shows a bare gap before, indistinguishable from a space. After, it renders as `report␉table.csv`. Note that `notes<LF>draft.md` looks the same in the project panel in both shots: that entry already called `single_line`, which already handled `\n`. That is precisely the asymmetry this PR removes. ### File finder Before, the newline also breaks the list itself — the `notes<LF>draft.md` row grows to two lines and overlaps the row beneath it. **Before**  **After**  Searching for `table` exercises the offset remapping, the match falling after the control character: **Before**  **After**  One thing this PR does **not** cover: the breadcrumb below the tab bar still renders the raw tab character, as it goes through a different path. ## Release Notes: - Fixed file names containing control characters, such as tabs and newlines, rendering unreadably in tabs, the project panel, the file finder, the tab switcher and terminal tab titles. --------- Co-authored-by: Kirill Bulatov <kirill@zed.dev> |
||
|
tidely
|
12f3994269 |
git_ui: Dismiss askpass prompts when requests end (#61292)
# Objective Fixes #47623 - When authenticating git commands using a security key through `askpass`. The modal which asks for user presence does not get dismissed even after the git command finishes successfully. ## Solution Add a cancellation task to the `AskPassModal`, which gets dropped when the requested operation completes. This cancellation task then dismisses the modal. ## Testing - I've tried authentication through `askpass` using my own security key. Testing both successful and failed authentication. - I've added tests which confirm that the modal gets dismissed when a task is cancelled, and that the cancellation is triggered when `ask_password` Task gets dropped. Willing to pair on review, message me on Slack. Showcase video left out because it would leak private information. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable Release Notes: - Fixed authentication prompts not dismissing automatically when using security keys with ssh |
||
|
Piotr Osiewicz
|
ff50948537 |
deps: Bump pathfinder_simd & fix upcoming rustc warnings (#62170)
While building Zed with nightly rustc I've noticed it doesn't compile because of good old pathfinder_simd. It also emits a bunch of warnings about use of f64 literals where f32 is expected, so I've fixed them - it should make future upgrades more straightforward. |
||
|
Ben Kunkle
|
81db8c68b2 |
workspace: Choose the replacement workspace inside MultiWorkspace::remove (#62141)
# Objective Follow-up to #62028. When archiving removed a thread's workspace, the replacement was derived from whichever sidebar row sat adjacent to the archived one. Rows are a flat list with project headers as separators, so archiving the oldest thread in a project selected the next project's newest thread and moved the user out of the project they were working in — and when that neighbor was remote, connected to its host just to pick a fallback. # Solution - `MultiWorkspace::remove` now chooses the replacement itself from a `RemovalIntent` (keep the project vs close it): a live workspace in the same project, the project's own roots when kept, the nearest retained neighbor, an adjacent local project, then an empty workspace. The workspaces being removed are excluded from that search in one place instead of five. - Sidebar neighbor selection stays within the entry's project section. - The three archive paths now share one removal orchestration, and the three "open the closed workspace first" helpers collapse into one. # Testing New tests cover: the keep-project fallback, neighbor selection staying inside the project section, and archiving with a mock-remote neighboring project never connecting to it. Each was verified to fail against the previous behavior. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [x] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed archiving a thread switching the window to a different project. - Fixed a possible crash when archiving a thread while its window was closing. |
||
|
Kirill Bulatov
|
01961bef59 |
Speed up cargo build -p zed compilation (#62059)
Splits the crate graph.
Before, the compilation graph: `editor → picker_preview → search →
project_panel → open_path_prompt → recent_projects → title_bar →
collab_ui → zed`
After, the compilation graph: `editor → picker_preview → search →
agent_ui → sidebar → zed`
With sccache disabled and project fully built, `touch
crates/editor/src/editor.rs` and `cargo build -p zed` took time
Before (
|
