Closes#19866
This PR supersedes #19228, as #19228 encountered too many merge
conflicts.
After some exploration, I found that for paths with the `\\?\` prefix,
we can safely remove it and consistently use the clean paths in all
cases. Previously, in #19228, I thought we would still need the `\\?\`
prefix for IO operations to handle long paths better. However, this
turns out to be unnecessary because Rust automatically manages this for
us when calling IO-related APIs. For details, refer to Rust's internal
function
[`get_long_path`](017ae1b21f/library/std/src/sys/path/windows.rs (L225-L233)).
Therefore, we can always store and use paths without the `\\?\` prefix.
This PR introduces a `SanitizedPath` structure, which represents a path
stripped of the `\\?\` prefix. To prevent untrimmed paths from being
mistakenly passed into `Worktree`, the type of `Worktree`’s `abs_path`
member variable has been changed to `SanitizedPath`.
Additionally, this PR reverts the changes of #15856 and #18726. After
testing, it appears that the issues those PRs addressed can be resolved
by this PR.
### Existing Issue
To keep the scope of modifications manageable, `Worktree::abs_path` has
retained its current signature as `fn abs_path(&self) -> Arc<Path>`,
rather than returning a `SanitizedPath`. Updating the method to return
`SanitizedPath`—which may better resolve path inconsistencies—would
likely introduce extensive changes similar to those in #19228.
Currently, the limitation is as follows:
```rust
let abs_path: &Arc<Path> = snapshot.abs_path();
let some_non_trimmed_path = Path::new("\\\\?\\C:\\Users\\user\\Desktop\\project");
// The caller performs some actions here:
some_non_trimmed_path.strip_prefix(abs_path); // This fails
some_non_trimmed_path.starts_with(abs_path); // This fails too
```
The final two lines will fail because `snapshot.abs_path()` returns a
clean path without the `\\?\` prefix. I have identified two relevant
instances that may face this issue:
-
[lsp_store.rs#L3578](0173479d18/crates/project/src/lsp_store.rs (L3578))
-
[worktree.rs#L4338](0173479d18/crates/worktree/src/worktree.rs (L4338))
Switching `Worktree::abs_path` to return `SanitizedPath` would resolve
these issues but would also lead to many code changes.
Any suggestions or feedback on this approach are very welcome.
cc @SomeoneToIgnore
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/21173
Rust-analyzer with `checkOnSave` enabled will push diagnostics for a
file after each diagnostics refresh (e.g. save, file open, file close).
If there's a file that is not open in any pane and has only warnings,
and the diagnostics editor has warnings toggled off, then
0. rust-analyzer will push the corresponding warnings after initial load
1. the diagnostics editor code registers
`project::Event::DiagnosticsUpdated` for the corresponding file path and
opens the corresponding buffer to read its associated diagnostics from
the snapshot
2. opening the buffer would send `textDocument/didOpen` which would
trigger rust-analyzer to push the same diagnostics
3. meanwhile, the diagnostics editor would filter out all diagnostics
for that buffer, dropping the open buffer and effectively closing it
4. closing the buffer will send `textDocument/didClose` which would
trigger rust-analyzer to push the same diagnostics again, as those are
`cargo check` ones, still present in the file
5. GOTO 1
Release Notes:
- Fixed diagnostics editor not scrolling properly under certain
conditions
This is a pure refactor, motivated by wanting to introduce to the
BufferStore new logic for opening staged and committed changes.
I found the `BufferStoreImpl` trait a little bit confusing, particularly
how the different implementors of the trait held a handle back to the
owning buffer store. I was able to reduce the amount of code
considerably (-78 lines) by using a two-variant enum instead, similar to
what we do for `LspStore`, `WorktreeStore` and `Worktree`.
Release Notes:
- N/A
The goal is to be able to hide these lines from a task output:
```sh
⏵ Task `...` finished successfully
⏵ Command: ...
```
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
I've observed that Zed's implementation of [Code Actions On
Format](https://zed.dev/docs/configuring-zed#code-actions-on-format)
uses the
[CodeActionContext.only](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeActionContext)
parameter to request specific code action kinds from the server. The
issue is that it does not filter out code actions from the response,
believing that the server will do it.
The [LSP
specification](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeActionContext)
says that the client is responsible for filtering out unwanted code
actions:
```js
/**
* Requested kind of actions to return.
*
* Actions not of this kind are filtered out by the client before being
* shown. So servers can omit computing them.
*/
only?: CodeActionKind[];
```
This PR will filter out unwanted code action on the client side.
I have initially encountered this issue because the [ZLS language
server](https://github.com/zigtools/zls) (until
https://github.com/zigtools/zls/pull/2087) does not filter code action
based on `CodeActionContext.only` so Zed runs all received code actions
even if they are explicitly disabled in the `code_actions_on_format`
setting.
Release Notes:
- Fix the `code_actions_on_format` setting when used with a language
server like ZLS
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
We occasionally see dates in the future appearing in our telemetry. One
hypothesis is that this is caused by a clock change while Zed is running
causing date math based on chrono to be incorrect.
Instant *should* be a more stable source of relative timestamps.
Release Notes:
- N/A
`create_buffer` calls `Buffer::local` which sets `file` to `None`
[here](f12981db32/crates/language/src/buffer.rs (L629)).
So there's no point in then immediately attempting to update maps that
rely on `file` being present.
Release Notes:
- N/A
Motivation for this is to make things more understandable while figuring
out #20775.
This is intended to be a refactoring that does not affect behavior, but
there are a few tricky spots:
* Previously `File.mtime()` (now `File.disk_state().mtime()`) would
return last known modification time for deleted files. Looking at uses,
I believe this will not affect anything. If there are behavior changes
here I believe they would be improvements.
* `BufferEvent::DirtyChanged` is now only emitted if dirtiness actually
changed, rather than if it may have changed. This should only be an
efficiency improvement.
Release Notes:
- N/A
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
This change ensures we always run LSPs with the project environment (in
addition to any overrides they provide). This helps ensure the
environment is
set correctly on remotes where we don't load the login shell environment
and
assign it to the current process.
Also fixed the go language to use the project env to find the go
command.
Release Notes:
- Improved environment variable handling for SSH remotes
Closes#19227
Since items listed in `.gitignore` file are not included in a worktree,
python virtual environment cannot be detected until venv directory is
unfolded from project panel and forcefully added into worktree. I didn't
come up with anything better than scanning fs directly. I'm not sure how
it will affect remote development. if at all.
Release Notes:
- Fixed detection of `detect_venv.directories` ignored by a worktree
A straight alphabetical order is arguably clearer, and avoids a large
initial delay when searching large repos.
Release Notes:
- Fixed a long initial delay when performing a project search in a large
repository.
This fixes the issue of multiple language servers showing up as `node`
in the language server logs dropdown.
It does this by changing `language_server.name()` to return the
adapter's name, not the binary name, and changing types to make sure
that we always use this.
Release Notes:
- Fixed language server names showing up only as `"node"`
---------
Co-authored-by: Sam Rose <hello@samwho.dev>
Co-authored-by: Bennet <bennet@zed.dev>
Closes#11529
Release Notes:
- Fixed an issue where the image preview would not update when the
underlying file changed
---------
Co-authored-by: Bennet <bennet@zed.dev>
This PR improves how we handle completions in buffers with multiple
LSPs.
Context: while working on
https://github.com/zed-industries/zed/issues/19777 with @mgsloan we
noticed that completion triggers coming from language servers are not
tracked properly. Namely, each buffer has `completion_triggers` field
which is read from the configuration of a language server. The problem
is, there can be multiple language servers for a single buffer, in which
case we'd just stick to the one that was registered last.
This PR makes the tracking a bit more fine-grained. We now track not
only what the completion triggers are, but also their origin server id.
Whenever completion triggers are updated, we recreate the completion
triggers set.
Release Notes:
- Fixed completions not triggering when multiple language servers are
used for a single file.
Reimplements `pet::EnvironmentApi`, trying to access the `project_env`
first
Closes#20177
Release Notes:
- Fixed python toolchain detection when worktree local path is set
Fixed the bug when shared ssh project did not account for client
changing things in their buffers.
Also ensures Prettier formatting workflow works for both ssh project
owner and ssh project clients.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Closes#19758
Release Notes:
- Added feature to show commit summary as part of the inline Git blame
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
The name (GitHub name) of the host was not displayed when sharing an ssh
project.
Previously we assumed that the a collaborator is a host if the
`replica_id` of the collaborator was `0`,
but for ssh project the `replica_id` is actually `1`.
<img width="329" alt="Screenshot 2024-10-28 at 18 16 30"
src="https://github.com/user-attachments/assets/c0151e12-a96f-4f38-aec1-4ed5475a9eaf">
Co-Authored-by: Thorsten <thorsten@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
When the language server gave us a prompt and we'd close the window, we
wouldn't release the `project` until the next `flush_effects` call that
came in when opening a window.
With this change, we no longer hold a strong reference to the project in
the future. Fixes the leak and makes sure we clean up the SSH connection
when closing a window.
Release Notes:
- N/A
Co-authored-by: Bennet <bennet@zed.dev>
Turns out that we used client-side `fs` to check whether something is a
directory or not, which obviously doesn't work with SSH projects.
Release Notes:
- N/A
---------
Co-authored-by: Bennet <bennet@zed.dev>
This PR adds support for selecting toolchains for a given language (e.g.
Rust toolchains or Python virtual environments) with support for SSH
projects provided out of the box. For Python we piggy-back off of
[PET](https://github.com/microsoft/python-environment-tools), a library
maintained by Microsoft.
Closes#16421Closes#7646
Release Notes:
- Added toolchain selector to the status bar (with initial support for
Python virtual environments)
Use `Fs` instead of `std::fs` and do entry existence checks better:
* first, check the worktree entry existence without any FS checks
* then, only for local cases, use `Fs` to check for abs_path existence
of items, in case those came from single-filed worktrees that got closed
and removed.
Remote entries do not get file existence checks, so might try opening
previously removed buffers for now.
Release Notes:
- N/A
Before this change, we would save the working directory *on the client*
of each shell that was running in a terminal.
While it's technically right, it's wrong in all of these cases where
`working_directory` was used:
- in inline assistant
- when resolving file paths in the terminal output
- when serializing the current working dir and deserializing it on
restart
Release Notes:
- Fixed terminals opened on remote hosts failing to deserialize with an
error message after restarting Zed.
Certain files like Rust stdlib ones can be opened by cmd-clicking on
terminal, editor contents, etc.
Those files will not belong to the current worktree, so a fake worktree,
with a single file, invisible (i.e. its dir(s) will not be shown in the
UI such as project panel), will be created on the file opening.
When the file is closed, the worktree is closed and removed along the
way, so those worktrees are considered ephemeral and their ids are not
stored in the database.
This causes issues on reopening such files when they are closed.
The PR makes Zed to fall back to opening the file by abs path when it's
not in the project metadata, but has the abs path stored in history or
in the opened items DB data.
Release Notes:
- Handle external worktree entries [re]open better
- Fixes modal closing when using the remote modal folder
- Fixes a bug with local terminals where they could open in / instead of
~
- Fixes a bug where SSH connections would continue running after their
window is closed
- Hides SSH Terminal process details from Zed UI
- Implement `cmd-o` for remote projects
- Implement LanguageServerPromptRequest for remote LSPs
Release Notes:
- N/A
