For ssh remoting lsps we'll need to have language server support
factored out of project.
Thus that begins
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Mikayla <mikayla@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
Fixes:
- [x] an issue where directories would only match by prefix, causing
both a directory and a file to be matched if in the same directory
- [x] An issue where you could not continue a file completion when
selecting a directory, as `tab` on a file would always run the command.
This effectively disabled directory sub queries.
- [x] Inconsistent rendering of files and directories in the slash
command
Release Notes:
- N/A
---------
Co-authored-by: max <max@zed.dev>
This PR removes the primary/secondary distinction for
`CachedLspAdapter`s.
After #15624 we weren't relying on the `is_primary` field anywhere, so
we can remove it.
Release Notes:
- N/A
This also refactors the BufferStore + WorktreeStore interfaces to make
them cleaner, more fully encapsulating the RPC aspects of their
functionality.
Release Notes:
- N/A
This is a ~small~ pure refactor that's a step toward SSH remoting. I've
extracted the Project's buffer state management into a smaller, separate
struct called `BufferStore`, currently in the same crate. I did this as
a separate PR to reduce conflicts between main and `remoting-over-ssh`.
The idea is to make use of this struct (and other smaller structs that
make up `Project`) in a dedicated, simpler `HeadlessProject` type that
we will use in the SSH server to model the remote end of a project. With
this approach, as we develop the headless project, we can avoid adding
more conditional logic to `Project` itself (which is already very
complex), and actually make `Project` a bit smaller by extracting out
helper objects.
Release Notes:
- N/A
Previously we were using a single globset::Glob in PathMatcher; higher
up the stack, we were then resorting to using a list of PathMatchers.
globset crate exposes a GlobSet type that's better suited for this use
case. In my benchmarks, using a single PathMatcher with GlobSet instead
of a Vec of PathMatchers with Globs is about 3 times faster with the
default 'file_scan_exclusions' values. This slightly improves our
project load time for projects with large # of files, as showcased in
the following videos of loading a project with 100k source files. This
project is *not* a git repository, so it should measure raw overhead on
our side.
Current nightly: 51404d4ea0https://github.com/zed-industries/zed/assets/24362066/e0aa9f8c-aae6-4348-8d42-d20bd41fcd76
versus this PR:
https://github.com/zed-industries/zed/assets/24362066/408dcab1-cee2-4c9e-a541-a31d14772dd7
Release Notes:
- Improved performance in large worktrees
Release Notes:
- Added a more detailed message in place of the generic `checking...`
messages when Rust-analyzer is running.
- Added a rate limit for language server status messages, to reduce
noisiness of those updates.
- Added a `cancel language server work` action which will cancel
long-running language server tasks.
---------
Co-authored-by: Richard <richard@zed.dev>
This fixes `project_tests::rescan_and_remote_updates` .
That test was actually correctly failing, revealing two bugs on Linux.
Release Notes:
- Fixed an issue where file renames were not detected on Linux.
- Fixed performance problems caused by excessive file system events on
Linux.
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This PR disables the
`project::project_tests::test_rescan_and_remote_updates` test on Linux,
as we've been seeing it fail quite consistently in CI.
We can re-enable it once we've had a chance to investigate and fix.
Release Notes:
- N/A
Note:
- We have disabled all tests that rely on Postgres in the Linux CI. We
only really need to test these once, and as macOS is our team's primary
platform, we'll only enable them on macOS for local reproduction.
- We have disabled all tests that rely on the font metrics. We
standardized on Zed Mono in many fonts, but our CoreText Text System and
Cosmic Text System proved to be very different in effect. We should
revisit if we decide to standardize our text system across platforms
(e.g. using Harfbuzz everywhere)
- Extended the condition timeout significantly. Our CI machines are slow
enough that this is causing spurious errors in random tests.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
TODO:
- [x] Finish GPUI changes on other operating systems
This is a largely internal change to how we report data to our
diagnostics and telemetry. This PR also includes an update to our blade
backend which allows us to report errors in a more useful way when
failing to initialize blade.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR is an internal refactor in preparation for remote editing. It
restructures the public interface of `Worktree`, reducing the number of
call sites that assume that a worktree is local or remote.
* The Project no longer calls `worktree.as_local_mut().unwrap()` in code
paths related to basic file operations
* Fewer code paths in the app rely on the worktree's `LocalSnapshot`
* Worktree-related RPC message handling is more fully encapsulated by
the `Worktree` type.
to do:
* [x] file manipulation operations
* [x] sending worktree updates when sharing
for later
* opening buffers
* updating open buffers upon worktree changes
Release Notes:
- N/A
The `worktree` crate mainly provides an in-memory model of a directory
and its git repositories. But because it was originally extracted from
the Project crate, it also contained lingering bits of code that were
outside of that area:
* it had a little bit of logic related to buffers (though most buffer
management lives in `project`)
* it had a *little* bit of logic for storing diagnostics (though the
vast majority of LSP and diagnostic logic lives in `project`)
* it had a little bit of logic for sending RPC message (though the
*receiving* logic for those RPC messages lived in `project`)
In this PR, I've moved those concerns entirely to the project crate
(where they were already dealt with for the most part), so that the
worktree crate can be more focused on its main job, and have fewer
dependencies.
Worktree no longer depends on `client` or `lsp`. It still depends on
`language`, but only because of `impl language::File for
worktree::File`.
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/10890
* removes `unwrap()` that caused panics for text elements with no text,
remaining after edit state is cleared but project entries are not
updated, having the fake, "new entry"
* improves discoverability of the FS errors during file/directory
creation: now those are shown as workspace notifications
* stops printing anyhow backtraces in workspace notifications, printing
the more readable chain of contexts instead
* better indicates when new entries are created as excluded ones
Release Notes:
- Improve excluded entry creation workflow in the project panel
([10890](https://github.com/zed-industries/zed/issues/10890))
Still TODO:
* Disable the new save-as for local projects
* Wire up sending the new path to the remote server
Release Notes:
- Added the ability to "Save-as" in remote projects
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
This introduces semantic indexing in Zed based on chunking text from
files in the developer's workspace and creating vector embeddings using
an embedding model. As part of this, we've created an embeddings
provider trait that allows us to work with OpenAI, a local Ollama model,
or a Zed hosted embedding.
The semantic index is built by breaking down text for known
(programming) languages into manageable chunks that are smaller than the
max token size. Each chunk is then fed to a language model to create a
high dimensional vector which is then normalized to a unit vector to
allow fast comparison with other vectors with a simple dot product.
Alongside the vector, we store the path of the file and the range within
the document where the vector was sourced from.
Zed will soon grok contextual similarity across different text snippets,
allowing for natural language search beyond keyword matching. This is
being put together both for human-based search as well as providing
results to Large Language Models to allow them to refine how they help
developers.
Remaining todo:
* [x] Change `provider` to `model` within the zed hosted embeddings
database (as its currently a combo of the provider and the model in one
name)
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Antonio <antonio@zed.dev>
This reverts commit caed275fbf.
NOTE: this should not be merged until #9668 is on stable and the
`ZedVersion#can_collaborate` is updated to exclude all clients without
that change.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
New list (used tasks are above the separator line, sorted by the usage
recency), then all language tasks, then project-local and global tasks
are listed.
Note that there are two test tasks (for `test_name_1` and `test_name_2`
functions) that are created from the same task template:
<img width="563" alt="Screenshot 2024-04-10 at 01 00 46"
src="https://github.com/zed-industries/zed/assets/2690773/7455a82f-2af2-47bf-99bd-d9c5a36e64ab">
Tasks are deduplicated by labels, with the used tasks left in case of
the conflict with the new tasks from the template:
<img width="555" alt="Screenshot 2024-04-10 at 01 01 06"
src="https://github.com/zed-industries/zed/assets/2690773/8f5a249e-abec-46ef-a991-08c6d0348648">
Regular recent tasks can be now removed too:
<img width="565" alt="Screenshot 2024-04-10 at 01 00 55"
src="https://github.com/zed-industries/zed/assets/2690773/0976b8fe-b5d7-4d2a-953d-1d8b1f216192">
When the caret is in the place where no function symbol could be
retrieved, no cargo tests for function are listed in tasks:
<img width="556" alt="image"
src="https://github.com/zed-industries/zed/assets/2690773/df30feba-fe27-4645-8be9-02afc70f02da">
Part of https://github.com/zed-industries/zed/issues/10132
Reworks the task code to simplify it and enable proper task labels.
* removes `trait Task`, renames `Definition` into `TaskTemplate` and use
that instead of `Arc<dyn Task>` everywhere
* implement more generic `TaskId` generation that depends on the
`TaskContext` and `TaskTemplate`
* remove `TaskId` out of the template and only create it after
"resolving" the template into the `ResolvedTask`: this way, task
templates, task state (`TaskContext`) and task "result" (resolved state)
are clearly separated and are not mixed
* implement the logic for filtering out non-related language tasks and
tasks that have non-resolved Zed task variables
* rework Zed template-vs-resolved-task display in modal: now all reruns
and recently used tasks are resolved tasks with "fixed" context (unless
configured otherwise in the task json) that are always shown, and Zed
can add on top tasks with different context that are derived from the
same template as the used, resolved tasks
* sort the tasks list better, showing more specific and least recently
used tasks higher
* shows a separator between used and unused tasks, allow removing the
used tasks same as the oneshot ones
* remote the Oneshot task source as redundant: all oneshot tasks are now
stored in the inventory's history
* when reusing the tasks as query in the modal, paste the expanded task
label now, show trimmed resolved label in the modal
* adjusts Rust and Elixir task labels to be more descriptive and closer
to bash scripts
Release Notes:
- Improved task modal ordering, run and deletion capabilities
This adds a new action to the editor: `editor: toggle git blame`. When
used it turns on a sidebar containing `git blame` information for the
currently open buffer.
The git blame information is updated when the buffer changes. It handles
additions, deletions, modifications, changes to the underlying git data
(new commits, changed commits, ...), file saves. It also handles folding
and wrapping lines correctly.
When the user hovers over a commit, a tooltip displays information for
the commit that introduced the line. If the repository has a remote with
the name `origin` configured, then clicking on a blame entry opens the
permalink to the commit on the code host.
Users can right-click on a blame entry to get a context menu which
allows them to copy the SHA of the commit.
The feature also works on shared projects, e.g. when collaborating a
peer can request `git blame` data.
As of this PR, Zed now comes bundled with a `git` binary so that users
don't have to have `git` installed locally to use this feature.
### Screenshots
### TODOs
- [x] Bundling `git` binary
### Release Notes
Release Notes:
- Added `editor: toggle git blame` command that toggles a sidebar with
git blame information for the current buffer.
---------
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Piotr <piotr@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
Co-authored-by: Mikayla <mikayla@zed.dev>
This fixes #[#9135](https://github.com/zed-industries/zed/issues/9135)
by introducing file/results limit to project search.
It does this by changing how project search works in multiple ways.
User-facing changes:
- Number files that are being searched is now limited to 5000
- Number of search results in all files is now limited to 10000
- If a limit is reached, search is stopped and a message is displayed
to the user
Under the hood, we also reworked `Project::search_local`:
- Code has been refactored so that the concurrency-logic is easier to
distinguish from the search logic.
- We now limit the number of concurrent `open_buffer` operations, since
that is being done on the main thread and can lead to beachballs when
finding a lot of results.
Note for reviewer:
@SomeoneToIgnore since you know this code, can you take a look at this?
The changes might look bigger than they are in certain places because I
only extracted code into functions, but the middle part — the sorting of
file paths — has changed in order to avoid too many tasks opening
buffers at the same time and making app unresponsive.
What's also curious is that I think there was a bug in that we searched
ignored entries _twice_: once in `search_snapshots` and then later in
the dedicated `search_ignored_entry` function. I changed the `entries()`
call in `search_snapshots` so that it's always `false`, but that caused
tests to fail (see `test_search_in_gitignored_dirs`). @bennetbo and I
think that there's some state in the Project that made the tests pass
before, because the last of the 3 assertions in that test only passes
when the other two queries run. So we changed the test to be more
stateless and included the possible fix in `search_snapshots`.
Release Notes:
- Fixed project-wide search leading to unresponsive application when
searching in ignored files, by limiting the number of files that are
searched (to 5000) and the number of overall search results to 10000.
Additional performance improvements have also been made in order to
offload more work onto a background thread.
([#9135](https://github.com/zed-industries/zed/issues/9135)).
---------
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
Co-authored-by: Bennet <bennetbo@gmx.de>
This is just a refactor. I noticed that we now have a `project_core`
crate, which mainly contains the `Worktree` type and its private
helpers, plus the project's settings.
In this PR, I've renamed that crate to `worktree` and did some minor
simplification to its module structure. I also extracted a new
`WorktreeSettings` settings type from the `ProjectSettings`, so that the
worktree settings could live in the worktree crate. This way, the crate
is now exclusively about worktree logic.
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/8874 and
https://github.com/zed-industries/zed/pull/7635
Closes https://github.com/zed-industries/zed/issues/7609
* mentions all `lsp::CodeActions` properties in the Zed client resolve
capabilities to remove more json out of general actions request
potentially
* removes odd `CodeActions.data` field checks, as that field is opaque
and is intended to store data, needed by the langserver to resolve this
code action
* if any `CodeAction` lacks either `command` or `edits` fields, tries to
resolve the action
This all effectively causes Zed to always fire an action resolve
request, since we update actions list (replacing the resolved actions
with the new, unresolved ones) via `refresh_code_actions`
9e66d48ccd/crates/editor/src/editor.rs (L3650)
that is being called on selections change and the actions menu open.
Yet, we do not query the resolve until the action is either applied
(selected in the list), or called for formatting, so it seems to be fine
to resolve them always, as it's not a frequent operation such as
reacting to every keystroke.
Release Notes:
- Fixed certain code actions not being resolved properly ([7609](https://github.com/zed-industries/zed/issues/7609))
---------
Co-authored-by: Derrick Laird <swampdonk@gmail.com>
This PR adds **internal** ability to run arbitrary language servers via
WebAssembly extensions. The functionality isn't exposed yet - we're just
landing this in this early state because there have been a lot of
changes to the `LspAdapter` trait, and other language server logic.
## Next steps
* Currently, wasm extensions can only define how to *install* and run a
language server, they can't yet implement the other LSP adapter methods,
such as formatting completion labels and workspace symbols.
* We don't have an automatic way to install or develop these types of
extensions
* We don't have a way to package these types of extensions in our
extensions repo, to make them available via our extensions API.
* The Rust extension API crate, `zed-extension-api` has not yet been
published to crates.io, because we still consider the API a work in
progress.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
