Closes#16919
repro step:
- add two worktree
- modify settings `"use_system_path_prompts" : false`
- `ctrl-n` create new file, typing any chars.
- `ctrl-s` save file
- typing any char, crashed.
Release Notes:
- Fixed crashed when setting `"use_system_path_prompts": false` or in
remote project with two or more worktree.
This PR puts the `zed: open account settings` action behind the
`zed-pro` feature flag, as it isn't supposed to be visible to users yet.
Closes https://github.com/zed-industries/zed/issues/17010.
Release Notes:
- N/A
This PR updates the extensions UI to truncate long text with an
ellipsis.
| Before | After |
|
--------------------------------------------------------------------------------------------------------------------------------------------------
|
--------------------------------------------------------------------------------------------------------------------------------------------------
|
| <img width="538" alt="Screenshot 2024-08-28 at 10 25 29 AM"
src="https://github.com/user-attachments/assets/98fda7b9-aac0-4c1b-903b-0d72070a166b">
| <img width="538" alt="Screenshot 2024-08-28 at 10 21 42 AM"
src="https://github.com/user-attachments/assets/948b1e66-3822-4c52-8483-522c28f393c7">
|
Release Notes:
- Improved the truncation of long author lists and descriptions in the
extensions view.
This PR reverts the addition of extension capabilities from #16953.
While these may end up being useful at some point, after some discussion
they don't seem like the exact fit for what we're looking to do right
now.
This reverts commit 8ec36f1e2b.
Release Notes:
- N/A
Before, when using `?` and `#` for backwards search it would initially
search for the previous match, but upon subsequent inputs to `n` and
`N`, `n` is always treated as "forward" and `N` is always treated as
"backward", instead of continuing the search direction.
now, if i use `?` or `#` for backward search, `n` will go to the
previous selection, and `N` will go to the next. Functionality stays the
same for `/` and `*`.
Release Notes:
- vim: Fixed `n` direction after searching backwards
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
As part of allowing LSPs to run remotely, we need to move LSP stuff
out of project. To do that we'd like to simplify the concurrency story
on project syncing.
Co-Authored-By: Max <max@zed.dev>
Release Notes:
- N/A
Co-authored-by: Max <max@zed.dev>
Ensures we sort paths in search the same as we do in panels.
Ideally we'd store things like this in the worktree, but the sort order
depends
on file vs directory, and callers generally don't know which they're
asking for.
Release Notes:
- N/A
This improves performance, because we don't render after every single
match/range that was added to the results.
I think for my example search it's twice as fast?
## Numbers
Recorded in debug mode (because it's 6:30pm and my poor computer has
spun its fan enough for today and also because you can see the change of
the effect more in debug mode), rendering `<` searched in `zed.dev`
repo:
- Before: `14.59558225s`
- After: `2.604320875s`
## Videos
Before (recorded in release mode):
https://github.com/user-attachments/assets/909260fa-3e69-49ab-8786-dd384e2a27ee
After (recorded in release mode):
https://github.com/user-attachments/assets/fc8a85d3-e575-470f-b59c-16a6df8b3f80
## Release Notes
Release Notes:
- Improved performance of rendering project-search results in the
multi-buffer after finding them.
This is a prototype change to improve latency of local project searches.
It refactors the matcher to keep paths "in-order" so that we don't need
to wait for all matching files to display the first result.
On a test (searching for `<` in zed.dev) it changes the time until first
result from about 2s to about 50ms. The tail latency seems to increase
slightly (from 5s to 7s) so we may want to do more tuning before hitting
merge.
Release Notes:
- reduces latency for first project search result
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Thorsten <thorsten@zed.dev>
This PR adds an initial notion of extension capabilities.
Capabilities are used to express the operations an extension is capable
of doing. This will provide further insights into what an extension can
do, as well as provide the ability to grant or deny the set of
capabilities.
Capabilities are defined in the `capabilities` field in the extension
manifest. This field contains an array of capabilities.
Each capability has a `kind` to denote the known capability it
corresponds to. Individual capabilities may have additional fields,
based on the `kind`.
Here's an example of some capabilities:
```toml
capabilities = [
{ kind = "download-file", host = "github.com", path_prefix = "owner/repo" },
{ kind = "npm:install", package = "@vue/language-server" },
]
```
In order to avoid a breaking change, the `capabilities` field is
currently optional and defaults to an empty array. This will allow us to
add support for extensions to define capabilities before we start
enforcing them.
Release Notes:
- N/A
This adds a new action: `editor: toggle inline completions`.
It allows users to toggle inline completions on/off for the current
buffer.
That toggling is not persistent and when the editor is closed, it's
gone.
That makes it easy to disable inline completions for a single text
buffer, for example, even if you want them on for other buffers.
When toggling on/off, the toggling also overwrites any language
settings. So if you have inline completions disabled for Go buffers,
toggling them on takes precedence over those settings.
Release Notes:
- Added a new editor action to allow toggling inline completions
(Copilot, Supermaven) on and off for the current buffer, taking
precedence over any settings.
Co-authored-by: Antonio <antonio@zed.dev>
As discussed in #15326, this font name should be included in the font
list since `settings.json` indicates that one can set the font to
`.SystemUIFont`.
Release Notes:
- N/A
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This is officially my weirdest performance fix to date; With large # of
windows opening app menu could take a lot of time (we're talking few
seconds with 9 windows, a minute with 10 windows). The fix is to make
one method pub(crate).. What?
<img width="981" alt="image"
src="https://github.com/user-attachments/assets/83b26154-0acd-43ef-84b3-4b85cde36120">
We were spending most of the time on clear_pending_keystrokes, which -
funnily enough - called itself recursively. It turned out we have two
methods; `AppContext::clear_pending_keystrokes` and
WindowContext::clear_pending_keystrokes. The former calls the latter,
but - due to the fact that `WindowContext::clear_pending_keystrokes` is
private and `WindowContext` derefs to `AppContext` - `AppContext` one
ended up actually calling itself! The fix is plain and simple - marking
WindowContext one as pub(crate), so that it gets picked up as a method
to call over `AppContext::clear_pending_keystrokes`.
Closes#16895
Release Notes:
- Fixed app menu performance slowdowns when there are multiple windows
open.
***Update**: after rebasing on top of
https://github.com/zed-industries/zed/pull/16915/ (that also changed how
search worked), the results are still good, but not 10x. Instead of
going from 10s to 500ms, it goes from 10s to 3s.*
This improves the performance of project-wide search by an order of
magnitude.
After digging in, @as-cii and I found that opening buffers was the
bottleneck for project-wide search (since Zed opens, parses, ... buffers
when finding them, which is something VS Code doesn't do, for example).
So this PR improves the performance of opening multiple buffers at once.
It does this by doing two things:
- It batches scan-requests in the worktree. When we search, we search
files in chunks of 64. Previously we'd handle all 64 scan requests
separately. The new code checks if the scan requests can be batched and
if so it, it does that.
- It batches `git status` calls when reloading the project entries for
the opened buffers. Instead of calling `git status` for each file, it
calls `git status` for a batch of files, and then extracts the status
for each file.
(It has to be said that I think the slow performance on `main` has been
a regression introduced over the last few months with the changes made
to project/worktree/git. I don't think it was this slow ~5 months ago.
But I also don't think it was this fast ~5 months ago.)
## Benchmarks
| Search | Before | After (without
https://github.com/zed-industries/zed/pull/16915) | After (with
https://github.com/zed-industries/zed/pull/16915)
|--------|--------|-------|------|
| `zed.dev` at `2b2a501192e78e`, searching for `<` (`4484` results) |
3.0s<br>2.9s<br>2.89s | 489ms<br>517ms<br>476ms | n/a |
| `zed.dev` at `2b2a501192e78e`, searching for `:` (`25886+` results) |
3.9s<br>3.9s<br>3.8s | 70ms<br>66ms<br>72ms | n/a |
| `zed` at `55dda0e6af`, searching for `<` (`10937+` results) |
10s<br>11s<br>12s | 500m<br>499ms<br>543ms | 3.4s<br>3.1s<br> |
(All results recorded after doing a warm-up run that would start
language servers etc.)
Release Notes:
- Performance of project-wide search has been improved by up to 10x.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Follow up to #16080
The idea is that the current context menu became a bit top-heavy over
time. Let's reorganisze it into four sections:
1. Finding symbols
2. Editing using lsp and similar
3. Copy/Cut/Paste
4. Getting file location
Release Notes:
- Reorganized context menu to be a bit less top heavy and have more
logical parts
Before (a giant part on top and two small ones on the bottom):
<img width="248" alt="Screenshot 2024-08-23 at 21 02 33"
src="https://github.com/user-attachments/assets/87a136c7-df16-4032-ba02-dea087fd8445">
After (much more balanced):
<img width="250" alt="Screenshot 2024-08-23 at 21 01 28"
src="https://github.com/user-attachments/assets/4aa48b8a-99f3-4315-b325-625a47ecd5b8">
It looks like this unwrap was introduced in
https://github.com/zed-industries/zed/pull/16534.
I think a worktree's `root_entry` can be null if it represents a
non-existent file that has not yet been saved. I hit a panic due to the
`unwrap` a couple of times on nightly.
Release Notes:
- N/A
This PR fixes an issue where active user counts were being computed
across _all_ measures instead of the per-minute measures.
We now compute them using the tokens per minute measure, as we're
concerned with usage in recent minutes.
Release Notes:
- N/A
Closes#14787.
I made a quick draft implementation of this feature request:
https://github.com/zed-industries/zed/issues/14787
I know how to use use gdb well, so lacking a built-in debugger is OK.
BUT... Speaking personally, setting breakpoints is 50% of what I want an
IDE to do for me when debugging. Having a feature where I can click,
copy, "b [paste]", is a huge step up from typing the whole thing in
manually. I figure this must be useful for other external tools, or even
just regular-human-communication too.
Open Questions:
* Does this belong in the right click menu? (I put it next to "Copy
Permalink" which is similar.)
* Probably not useful enough to get a default keymap?
* Relative vs absolute path?
* Does this need tests?
Release Notes:
- Added `editor: copy file location` command to copy the current file
location (FILE:LINE) to the clipboard
([#14787](https://github.com/zed-industries/zed/issues/14787)).
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Release Notes:
- Fixed the issue related to the project wide search being stuck when
project contains .fifo files
- Might potentially solve the following issue
https://github.com/zed-industries/zed/issues/7360
We've noticed performance issues in long conversations with assistants;
the profiles pointed to slowiness in WrapMap (and indeed there were some
low hanging fruits that we picked up in
https://github.com/zed-industries/zed/pull/16761). That however did not
fully resolve the issue, as WrapMap still cracked through in profiles;
basically, the speedup I've landed has just moved the post elsewhere.
The higher level issue is that we were trying to refresh message headers
for all messages, irrespective of whether they've actually needed to be
updated. This PR fixes that by using `replace_blocks` API where
possible.
Release Notes:
- Improved performance of Assistant Panel with long conversations.
This helps debug what steps are taken and where
the compiled extension ended up.
Also remove duplicate "compiling Rust extension" / "compiling rust
extension" text - it's confusing.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Piotr Osiewicz
Evren Senandevrensen467
Conrad Irwin
CharlesChen0823
Marshall Bowers
Joseph T Lyons
Kirill Bulatov
Thorsten Ball
fletcher gornickandConrad Irwin
Kyle Kelley
dovakin0007
kshokhin
张小白andMarshall Bowers
Peter Tripp
0x2CAandConrad Irwin
Max Brunsfeld
moshyfawn
apricotbucket28
Stanislav Alekseev
Toni CárdenasandKirill Bulatov
Scott LembckeandMarshall Bowers
TheCub3
Nate Butler
Berkus DeckerandMarshall Bowers