This PR fixes the license for the `anthropic` crate.
It was mistakenly licensed as AGPL, despite being used outside of
collab. It should be licensed as GPL.
Release Notes:
- N/A
Closes#23383
This PR changes `project_panel::NewSearchInDirectory` to open project
search filtered by the parent directory when triggered on a file, rather
than doing nothing.
Release Notes:
- Improved `project_panel::NewSearchInDirectory` to search the parent
directory when triggered on a file
This PR prevents situations like
https://github.com/zed-industries/zed/pull/23850, which caused our linux
nightly build to fail to open at all.
This PR also sorts the GPUI build and dev dependencies out from the sea
of platform specific dependencies.
Release Notes:
- N/A
Limits the size of the buffer excerpt and the size of change history.
Release Notes:
- N/A
---------
Co-authored-by: Richard <richard@zed.dev>
Co-authored-by: Joao <joao@zed.dev>
Part of https://github.com/zed-industries/zed/pull/21092
As we're already depending on and using `tokio` to run `reqwest`, I've
added a crate to make running tokio futures more convenient. This should
unblock the Bedrock Cloud Model provider PR.
Note that since the `gpui_tokio` code is nearly trivial glue and I
expect that it will be useful for the nascent GPUI ecosystem, I've
elected to license it under Apache 2, like GPUI itself, instead of our
normal GPL license for Zed code.
Release Notes:
- N/A
> **Note:** https://github.com/zed-industries/zed/pull/23813 should be
merged first!
@nathansobo and I paired on revising this menu, including adding the
"Predict Edits at Cursor" menu item (to make the keyboard shortcut more
discoverable; clicking it makes the inline edits show up, as shown in
the second screenshot) and switching from "Hide/Show" language to
checkboxes.
## Before
<img width="282" alt="Screenshot 2025-01-28 at 4 51 37 PM"
src="https://github.com/user-attachments/assets/309c82c1-8fb5-44db-950e-1a8789a63993"
/>
## After
<img width="1138" alt="Screenshot 2025-01-28 at 4 50 05 PM"
src="https://github.com/user-attachments/assets/302a126c-9389-42a4-bb7d-2896bce859e7"
/>
We also switched to use `SharedString` in more places, where it made
more sense.
@danilo-leal This isn't necessarily *exactly* what we want, but we were
pairing and decided to get it in a state where we can actually try it
out and tweak from here.
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Closes#20762
Release Notes:
- N/A
---
Enable MSAA for Anti-Aliasing to Path (`cx.paint_path`) for drawing a
better vector graphics.
```bash
cargo run -p gpui --example gradient --features macos-blade
cargo run -p gpui --example gradient
cargo run -p gpui --example painting --features macos-blade
cargo run -p gpui --example painting
```
**Before**
<img width="1089" alt="image"
src="https://github.com/user-attachments/assets/0ae7240f-4ba9-4ef5-896c-e436c1282770"
/>
**After**
<img width="944" alt="image"
src="https://github.com/user-attachments/assets/71a07ae8-be54-452c-aacc-b8cec1f810c0"
/>
## TODO
- [x] Support Metal and Blade.
- [x] Detect system support to set up sample count.
- [x] Fix extra lines between Path vertices wait #22808 to merge.
Ref https://github.com/kvark/blade/pull/213
Ask @kvark to review.
I am not sure if there is anything I missed. I modified it according to
the
[particle](https://github.com/kvark/blade/tree/main/examples/particle)
example of Blade project. But the difference is that after the first
MSAA render, I did not do it a second time, I tested it and found it was
not necessary.
This PR does some somewhat light UI adjustment to the Assistant 2
settings view. The Prompt Library section should feature the default
prompts in the future, so that's why it's been separated that way.
<img width="800" alt="Screenshot 2025-01-29 at 2 59 59 PM"
src="https://github.com/user-attachments/assets/7b033bde-51ab-44d5-9e53-3f72b8ff5f51"
/>
Release Notes:
- N/A
This PR makes it so staff edit predictions now go through Cloudflare
Workers instead of going to the LLM service.
This will allow us to dogfood the new LLM worker to make sure it is
working as expected.
Release Notes:
- N/A
TODO:
- [x] BackgroundOrientation
- [x] PatternDash
- [x] `pattern_horizontal_dash` & `pattern_vertical_dash`
- [x] Metal dash shader
- [x] Blade dash shader
- [x] Update ui::Divider to use new pattern
---
This PR introduces proper dashed dividers using the new `PatternDash`
background shader.
Before this we were using 128 elements to create a dashed divider, which
is both expensive, and would not scale beyond a certain size. This
allows us to simplify the divider element as well.
Changes:
- Adds `BackgroundOrientation` to `gpui::color::Background` to allow
specifying a direction for a pattern
- Adds the PatternDash pattern variant
- Updates `ui::Divider`'s dashed variants to be more efficient
Misc:
- Documents the `ui::Divider` component
- Treat `.metal` files as `C` in the Zed project until we get some metal
syntax highlighting.
Release Notes:
- N/A
This PR adds a new internal `POST /snowflake/events` endpoint to collab.
This endpoint is protected with the admin token like our other internal
endpoints.
This endpoint accepts a `SnowflakeRow` in the body and writes it to the
AWS Kinesis stream.
Release Notes:
- N/A
Previously we returned an error when the interpolation failed in
`process_completion_response`.
However, it is not an error when interpolation returns `None`. That just
means that the predicted edits can be discarded, because the user typed
something that is not a subset of what the model predicted OR if the
model responds with a no-op.
```
2025-01-29T09:44:30.221135+01:00 [ERROR] zeta prediction failed
Caused by:
Interpolated edits are empty
```
Release Notes:
- N/A
Required using a global `LazyLock<Mutex<AppNotifications>>` instead of a
context global because settings errors first occur before initialization
of the notifications global.
Release Notes:
- Errors in settings file are now reported in UI on startup.
# Add AnyBrackets text object for Vim mode
## Overview
This PR introduces a new text object `AnyBrackets` that allows
operations on the closest matching pair of brackets, regardless of the
bracket type. This enhances the editing experience by reducing the need
to identify specific bracket types before performing text operations.
By default, this feature is NOT mapped to any key in vim.json. However,
it can be enabled manually, and the recommended key for mapping is b:
If you want to add it to your zed keymap config you need to add the
following config:
```json
{
"context": "vim_operator == a || vim_operator == i || vim_operator == cs",
"bindings": {
"b": "vim::AnyBrackets"
}
}
```
## Features
- New text object that works with parentheses `()`, square brackets
`[]`, curly braces `{}`, they are also know as round brackets, square
brackets and curly brackets in english.
- Automatically finds the closest matching pair of any bracket type
- Works with all standard Vim operators (delete, change, yank)
- Supports both "inside" and "around" variants (`i` and `a`)
## Usage Examples
```vim
# Delete inside the closest brackets
di( # Works on (), [] or {} depending on which is closest
# Change around the closest brackets
ca[ # Works on (), [] or {} depending on which is closest
# Visual select inside the closest brackets
vi{ # Works on (), [] or {} depending on which is closest
```
# References:
- Based on the popular plugin https://github.com/echasnovski/mini.ai
# Important Notes
This PR also fixes a bug with nested quotes on AnyQuotes, now it works
fine with any type of quotes or brackets.
Please take a look at the new tests to understand the expected behavior.
Release Notes:
- vim: Add `ab`/`ib` "AnyBrackets" text objects that are the smallest of
`a(`, `a[` or `a{` or `i(`, `i[` or `i{`
- vim: Fix aq/iq "AnyQuotes" text objects when they are nested
This fixes an edge case when two hunk controls button groups were
visible (due to having text cursor on one hunk, and mouse cursor on the
other). In that situation, the mouse states for the two button groups
would mirror.
Release Notes:
- N/A
This PR fixes a typo in the error that occurs when trying to construct
an AWS Kinesis client and the `kinesis_region` value is missing.
Release Notes:
- N/A
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.
