TODO:
- [x] Add BackgroundTag::PatternSlash
- [x] Support metal slash pattern fills
- [x] Support blade slash pattern fills
---
Adds support for a new background type in gpui, `pattern_slash`.
Usage:
```rust
div().size(px(56.0)).bg(pattern_slash(gpui::red()))
```
This will create a 56px square with a red slash pattern fill.
You can run the pattern example with `cargo run -p gpui --example
pattern`:
---
After talking with @as-cii at length about how we want to support
patterns in gpui, we decided for now we'll simply add a new
BackgroundTag specific to this pattern.
It isn't the best long term plan however – we'll likely want to
introduce the concept of a `Fill` at some point so we can have
`Fill::Solid`, `Fill::Gradient(LinearGradient)`, etc in the future.
The pattern is designed to seamlessly tile vertically for elements of
the same height. For example, for use in editor line backgrounds:
---
Release Notes:
(do we do gpui release notes?)
- Adds support for slash pattern fills in `gpui`.
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This PR fixes an issue introduced in
https://github.com/zed-industries/zed/pull/20551/ that would prevent
models with unknown IDs from working in the LLM service.
We only need to look up a model from its ID for the beta headers, and if
we can't find that particular model we should fall back to the default
beta headers instead of bailing out completely,
Release Notes:
- N/A
In both `thread` and `prompt editor` the context file picker, gitignored
files are hidden (as expected) when searching files by path, but they
are still shown initially as you create the file picker.
Plus, selecting gitignored files in the `prompt editor` is bugged and
collapses everything.
This PR settles on not showing gitignored files to solve these
inconsistencies.
Release Notes:
- Fix gitignored files filter occasionally not working in context file
picker.
Now both remote collab and ssh remote get entries shown and updated in
the git panel.
This seems to be quite a step towards remote git support, hence
submitting a PR.
Further steps: remove `get_local_repo` and allow getting the repo from
`Worktree`, not its local counterpart + have another, remote impl of the
`GitRepository` trait.
Release Notes:
- N/A
This fixes the panics we we're seeing in `EditPreview::highlight_edits`.
The reason for this was that we were interpolating edits incorrectly.
Here's an example:
```rust
let a = 0; // existing code
let c = 2; // suggested by edit prediction
```
The edits would look like this: `[(Point(1, 0)..Point(1, 0), "let c =
2;"]`
Now i type:
```rust
let a = 0; // existing code
let b = 1; // added this line
let c = 2; // suggested by edit prediction
```
Before this change, the `interpolate` function would allow insertions
before the edit prediction edits, the anchors will move to the next
line.
The edits would look now like this: `[(Point(2, 0)..Point(2, 0), "let c
= 2;"]`
However, now we end up with a call to `EditPreview::highlight_edits`,
with the following parameters:
- current_snapshot:
```rust
let a = 0;
let b = 1;
```
- edits: `[(Point(2, 0)..Point(2, 0), "let c = 2;"]`
- applied_edits_snapshot:
```rust
let a = 0;
let c = 2;
```
And here you can see the issue, applying the `edits` to the
`current_snapshot` should always end up re-creating the text that is
present in the `applied_edits_snapshot`. That is not the case here
though, meaning that the offsets in the new buffer are not correct,
which can either lead to a confusing popup or a crash if the suggestion
is at the end of the file.
Here's a real world example (edit prediction is ONLY suggesting to
delete a new line):
<img width="487" alt="Screenshot 2025-01-27 at 13 05 26"
src="https://github.com/user-attachments/assets/a0a8064e-8cfa-48b2-9f1c-efc2d0d9d7d4"
/>
We fixed this by only allowing interpolation if the user is editing
after all the edit predictions OR if the user edit is a subset of the
model suggestion.
Co-Authored-by: Antonio <antonio@zed.dev>
Release Notes:
- N/A
Co-authored-by: Antonio <antonio@zed.dev>
Following up on #20763, this PR adds support for module- and class-level
docstrings, adds "additional docstrings" as described in [PEP
257](https://peps.python.org/pep-0257/), and fixes function-level
docstrings so that only the first string literal in a function gets
treated as a docstring.
One question that occurs to me is: Would it be good to capture attribute
and additional docstrings differently from regular docstrings? E.g.
`@string.doc.attribute`, `@string.doc.additional`? PEP 257 mentions that
unlike regular docstrings, these docstrings are ignored by the
interpreter (regular docstrings get added as the `__doc__` property of
the object they document), so I can see someone potentially wanting to
style them a little differently.
Release notes:
* Added Python syntax highlighting for class- and module-level
docstrings, additional docstrings, and improved recognition of
function-level docstrings.
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
This PR adds menu item for `workspace::OpenFiles` in app menu on Linux
and Windows.
Context:
When opening a file or folder on Linux and Windows via the native file
picker, the picker can be either in file-only mode or folder-only mode.
This means you have to open it already knowing whether you want to open
a file or a folder, unlike macOS, which lets you choose either in the
same picker.
For this reason, a new action, `workspace::OpenFiles`, was recently
added for Linux and Windows. This is basically file-only mode, alongside
the existing `workspace::Open` action, which is folder-only. In macOS,
the `workspace::Open` action is sufficient to open both file and folder.
Before:
<img
src="https://github.com/user-attachments/assets/67dc95d6-e98d-438a-9568-570e87617f85"
alt="Before" width="200" />
After:
<img
src="https://github.com/user-attachments/assets/d0ffd02c-0f48-4edc-b426-4d430f2e0c86"
alt="After" width="200" />
Release Notes:
- Added "Open File" action in file menu for Linux and Windows.
Closes#18702
This is take 2 of [my previous
PR](https://github.com/zed-industries/zed/pull/19555), which was closed
due to inactivity and merge conflicts.
**Cause**:
The editor's horizontal scroll width only considers the longest line in
the buffer, using `layout_line` for `longest_row`. The inline blame
width isn’t included in it because it is just a decoration on top of the
line (think of like CSS absolute) and not part of its actual content.
This causes blame to overflow.
**Solution**:
Along with `longest_row` width we also add that line's inline blame
width for scroll width calculation. We also have to add some padding
that is between inline blame and line's content.
**Alternate Solution**:
In my previous PR, instead of adding the inline blame width of the
longest line for scroll width calculation, I used the inline blame of
the current line the cursor is on (since we only see the blame for the
current line). I added that to the current line's width, giving us the
full width of that row. Then, we compare that row's width with the
longest row width and use the max of the two for the scroll width
calculation.
While this solution seems clever, it's overly complicated and could
cause issues, like the scroll width changing every time you move the
cursor up or down. I don't think we should go with this, but I'm open to
suggestions.
**Preview**:
Before:
https://github.com/user-attachments/assets/01ef90cf-06e7-4ebb-8bd1-637a53e0654e
After:
https://github.com/user-attachments/assets/b13616de-bdea-4da4-b32d-9c4104448166
Release Notes:
- Fixed inline Git blame not visible on long lines due to overflow.
Closes#19192
1. Changed the drag overlay of entries for better visibility of where to
drop.
2. Folded directories (except for the last folded one) will be
highlighted as drop targets.
3. The delimiter between folded directories prevents the directory
highlight from losing focus and acts as part of the directory to avoid
flickering.
This works just like VS Code does.
[fold-drop.webm](https://github.com/user-attachments/assets/853f7c5e-3492-4f56-9736-6d0e3ef09325)
Release Notes:
- Added precise drag-and-drop for files onto folded directories in the
Project Panel.
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Closes#15966
This PR adds `Alt/Opt+Click` to expand or collapse a directory and all
its contents.
Context:
The current `expand_entry` scans immediate child subdirectories if they
aren’t loaded, while `expand_all_for_entry` scans the entire subtree.
The latter takes longer, so we wait for it to complete to ensure
accurate results.
For full directory scan, instead of using
`refresh_entries_for_paths(vec![path])`, which requires specifying all
explicit paths to refresh, we use `add_path_prefix_to_scan`, which
eliminates the need to list every path. Both methods internally call
`reload_entries_for_paths`, which invokes `should_scan_directory`. This
determines whether to scan deeper based on a path prefix match between
the given directory and its subdirectories, returning `true` for
`add_path_prefix_to_scan`.
The existing code handles scanning, removing path prefixes after scans
complete, and managing ignored directories.
How it works (Expand):
1. Alt clicking on non-ignored closed directory, expands it and all its
subdirectories, except ignored subdirectories. This helps while working
on mono repos, where you might not want to expand dirs like
`node_modules`, `dist`, etc or git submodules, when you expand any root
dir.
In example, `draft` and `posts` dir are ignored dir.
[expand-1.webm](https://github.com/user-attachments/assets/07d3f724-0757-408f-b349-5beb4ee8440e)
2. Alt clicking on ignored closed directory, expands it and all its
subdirectories. This is when you explicitly want to do it, on dirs like
`node_modules`, `dist`, etc.
In example, `dist` dir is ignored dir.
[expand-2.webm](https://github.com/user-attachments/assets/99e55883-ab1a-4a9c-a0f0-48026991a922)
3. In case of auto folded subdirectories, expand all action will take
precedence over it. That is, it will unfold all the subdirectories
inside clicked dir. This is intentional, as user explicitly wants to
reveal as much content as possible. (This is my personal opinion on how
it should work).
[expand-3.webm](https://github.com/user-attachments/assets/f20b0311-e92a-4e34-b640-1469b0d6fa16)
How it works (Collapse):
1. Alt clicking any opened directory will collapse it and all its
children, whether ignored or not. This is when you want to start from a
fresh state.
2. When auto fold is enabled in settings, collapse action will also fold
all subdirectories that it can fold. This is to bring it back to its
fresh state as mentioned above.
[collapse-1-2.webm](https://github.com/user-attachments/assets/74db6cee-0afa-406b-a9a2-7421083a2c2a)
Future:
- Using keybinding to expand/collapse all for selected entry
- Handle expand/collapse all for folded entry
Todos:
- [x] Expand entries logic
- [x] Handle remote worktree for expand
- [x] Figure out scan complete status
- [x] Move expansion logic to status update event
- [x] Collapse entries logic
- [x] Handle fold/unfold subdirs interaction
- [x] Do not expand git ignored sub-dirs
- [x] Tests
- [x] Test Remote
Release Notes:
- Added Alt/Opt+Click functionality to expand or collapse a directory
and all its contents.
I recently noticed that on my Windows 11 machine, Zed no longer receive
the `WM_DWMCOLORIZATIONCOLORCHANGED` message when the system theme
changes. This functionality was present in the past. While this change
might be unexpected, it's understandable given Microsoft's history of
system updates.
This pull request proposes an alternative approach using the
`WM_SETTINGCHANGE` message to handle theme changes.
Release Notes:
- N/A
We used to wait 6 months to close stale issues. Jono suggested 1 month.
I'm sort of splitting the difference and adding a bit of buffer. We can
adjust again later on, if we want.
Release Notes:
- N/A
Closes#21625#17401#16426
This is how the opening of a file works currently:
1. We first check if the file is part of any existing worktree. If it
is, we focus on that file in the worktree, and the window is activated.
2. If the file is not part of any worktree, we open it in the first
local non-collab workspace we find and activate that window. This is the
bug that the issues are based on.
This PR fixes it by modifying the second part of the above step, where
the file is not part of any worktree. Now, we will first open the file
in the active window, but only if the active window is local and
non-collab. This resolves the issue. If the file can't be opened in the
active window due to the local non-collab check, we will carry out the
existing logic of opening the file in whichever window is local and
non-collab.
I have tested this using the "workspace::OpenFiles" action, and
"workspace::Open" also uses the same method. That is, it will work on
all platforms.
Future: Some users also mentioned there should be a setting for whether
we should open a non-workspace file in the existing window or in a
separate new window. However, this seems out of scope, and a new issue
should be created for this.
#9370 is related, but this likely doesn't fix it, as it deals with how
macOS Finder's "Open with" handles files. I don't have macOS to test,
but this PR won't resolve it if Finder always opens a new window.
Release Notes:
- Fixed the issue where a file outside of the workspace was opening in a
random window instead of the last active window.
This fixes an issue introduced in #22994 where soft wrap would
recalculate for the entire buffer when editing.
Release Notes:
- N/A
---------
Co-authored-by: Conrad <conrad@zed.dev>
This PR adds the `show_tab_bar_buttons` under `tab_bar` that allows
hiding the "New", "Split Pane", and "Zoom" buttons to the left of the
pane tab bar.
Release Notes:
- Added a new `show_tab_bar_buttons` setting, under `tab_bar`, that
enables hiding the pane tab bar buttons.
This PR adds really tiny visual adjustments to the assistant 2. I guess
the most note-worthy thing here is that I separated the `title` for
History views into two just because I wanted to render the `/` smaller
and lighter. 😬
Release Notes:
- N/A
Fix bugs caused by the window context PR, where the window could be on
the stack and is then requested from the App.
This PR also adds derive macros for `AppContext` and `VisualContext` so
that it's easy to define further contexts in API code, such as
`editor::BlockContext`.
Release Notes:
- N/A
- Added support for DeepSeek as a new language model provider in Zed
Assistant
- Implemented streaming API support for real-time responses from
DeepSeek models.
- Added a configuration UI for DeepSeek API key management and settings.
- Updated documentation with detailed setup instructions for DeepSeek
integration.
- Added DeepSeek-specific icons and model definitions for seamless
integration into the Zed UI.
- Integrated DeepSeek into the language model registry, making it
available alongside other providers like OpenAI and Anthropic.
Release Notes:
- Added support for DeepSeek to the Assistant.
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
This PR changes the `ThreadStore` constructor to not block on reloading
the threads before we finish initializing it.
This allows us to make the constructor synchronous instead of
asynchronous.
Release Notes:
- N/A
This PR fixes an issues where clicking the "Open Configuration" button
wasn't opening the configuration.
We needed to change how the action was dispatched after #22632.
Release Notes:
- N/A
This PR adds some logging so we can debug the issues some folks have
been having with Assistant2 not getting initialized properly.
All the logs are prefixed with `[assistant2-debug]` so they're easier to
pick out of the logs, as well as find them later to clean up once we've
diagnosed the issue.
Release Notes:
- N/A
Dev builds show panics related to completion label normalization
<details>
<summary>Panic</summary>
```
index out of bounds: the len is 103 but the index is 103
zed::reliability::init_panic_hook::{{closure}}::h78130eff43c84f6f+110375521
std::panicking::rust_panic_with_hook::hfe205f6954b2c97b+87457752
std::panicking::begin_panic_handler::{{closure}}::h6cb44b3a50f28c44+87456967
std::sys::backtrace::__rust_end_short_backtrace::hf1c1f2a92799bb0e+87449337
rust_begin_unwind+87456084
core::panicking::panic_fmt::h3d8fc78294164da7+7033011
core::panicking::panic_bounds_check::h9397cb495d89a72d+7033511
project::lsp_store::ensure_uniform_list_compatible_label::haf80316ce11edd67+72663592
project::lsp_store::populate_labels_for_completions::{{closure}}::hc93c3c540ef7d2d6+72642960
project::lsp_store::LspStore::completions::{{closure}}::{{closure}}::hb4b5432e24432ca8+72336627
async_task::raw::RawTask<F,T,S,M>::run::hf444c3dc07dd583b+68504803
<gpui::platform::linux::wayland::client::WaylandClient as gpui::platform::linux::platform::LinuxClient>::run::hbf5a316eb781a10d+50646579
gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run::hc85518d4552fc4cd+50496669
gpui::app::App::run::hca4e2eaf984ca6f6+109905269
zed::main::h849467ac1a6d32c9+110413414
std::sys::backtrace::__rust_begin_short_backtrace::h81b5ee155a7cf505+110835475
std::rt::lang_start::{{closure}}::h48a83f884cfb6865+110834761
std::rt::lang_start_internal::h5e7c81cecd7f0954+87382485
main+110425932
__libc_start_call_main+22789462491720
__libc_start_main_alias_1+22789462491915
_start+10436606
```
</details>
This can only happen when either `label.runs` or `label.filter_range`
has a range that's larger than the label text, which is an error.
Instead of panicking, log such errors and fall back to last index (which
is not really helpful, but still).
Release Notes:
- N/A
