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>
This is a refactor, follow-up to the work we've been doing on loading
WASM language extensions.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
This PR adds the initial support for loading extensions in Zed.
### Extensions Directory
Extensions are loaded from the extensions directory.
The extensions directory has the following structure:
```
extensions/
installed/
extension-a/
grammars/
languages/
extension-b/
themes/
manifest.json
```
The `manifest.json` file is used internally by Zed to keep track of
which extensions are installed. This file should be maintained
automatically, and shouldn't require any direct interaction with it.
Extensions can provide Tree-sitter grammars, languages, and themes.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Based on the great work in
https://github.com/zed-industries/zed/pull/7130 , now sends this data
```
[crates/lsp/src/lsp.rs:588] ClientInfo { name: name.to_string(), version: Some(version.to_string()) } = ClientInfo {
name: "Zed Dev",
version: Some(
"0.122.0",
),
}
```
with every LSP server initialization.
Release Notes:
- Added Zed name and version to LSP InitializeParams requests
The diagnostics are collected and available still, since that might become a settings/UI toggle later.
Also, buffer diagnostics are still updated for gitignored files.
This is the first batch of improvements to current project search. There
are few things we can do better still, but I want to get this out in
next Preview.
Most of the slowness at this point seems to stem from updating UI too
often.
Release Notes:
- Improved project search by making it report results sooner.
---------
Co-authored-by: Julia Risley <julia@zed.dev>
This PR allows you to customize Zed's settings within a particular
folder by creating a `.zed/settings.json` file within that folder.
Todo
* [x] respect folder-specific settings for local projects
* [x] respect folder-specific settings in remote projects
* [x] pass a path when retrieving editor/language settings
* [x] pass a path when retrieving copilot settings
* [ ] update the `Setting` trait to make it clear which types of
settings are locally overridable
Release Notes:
* Added support for folder-specific settings. You can customize Zed's
settings within a particular folder by creating a `.zed` directory and a
`.zed/settings.json` file within that folder.
