Fixes https://github.com/zed-industries/zed/issues/5291
Release Notes:
- Fixed a bug where the 'toggle comments' command didn't use the right
comment syntax in JSX and TSX elements.
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
gopls would send us watch patterns like `**/*.mod` and we'd fall back to
watching `/`.
Release Notes:
- Fix file watching for go projects resorting to watching the fs root.
Co-authored-by: Thorsten <thorsten@zed.dev>
Release Notes:
- Changed built-in language support (Rust, Go, C, YAML, ...) to lookup
language-server specific settings locally in project directory first
before falling back to global value.
---------
Co-authored-by: Bennet <bennet@zed.dev>
This is a follow-up to #17075 to spawn a login shell when getting the
environment for projects.
The reason why we didn't do it before is that we only used the
environment for certain language servers and not a lot of other things,
like tasks.
But with #17075 we now use the project more often and use it as the
_base_ environment for tasks/terminals.
Before the change, terminals and tasks would inherit the Zed process'
environment, including PATH and so on. After the change, we would set
the environment, overwriting the PATH instead of merging. But the
non-login shell environment is a subset of the login-shell environment.
Release Notes:
- Fixed environment variables used per project in terminals/tasks
overwriting the base environment and not making use of a login-shell
environment.
We would log every time we'd lookup a language server for a file and
we'd also log "starting language server" even though we were about to
only download it and not start it.
Release Notes:
- N/A
This reverts commit 8a1e8e37bb (PR #17435)
because it creates a panic when joining a collab project.
Stack trace of the panic:
```
Thread "main" panicked with "ProjectLspAdapterDelegate cannot be constructedd on an ssh-remote yet" at crates/project/src/lsp_store.rs:6332:13
0: backtrace::backtrace::libunwind::trace
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/libunwind.rs:116:5
backtrace::backtrace::trace_unsynchronized::<<backtrace::capture::Backtrace>::create::{closure#0}>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/mod.rs:66:5
1: backtrace::backtrace::trace::<<backtrace::capture::Backtrace>::create::{closure#0}>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/mod.rs:53:14
2: <backtrace::capture::Backtrace>::create
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/capture.rs:197:9
3: <backtrace::capture::Backtrace>::new
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/capture.rs:162:22
4: zed::reliability::init_panic_hook::{closure#0}
at /Users/thorstenball/work/zed/crates/zed/src/reliability.rs:58:29
5: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/alloc/src/boxed.rs:2084:9
std::panicking::rust_panic_with_hook
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:808:13
6: std::panicking::begin_panic_handler::{{closure}}
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:667:13
7: std::sys::backtrace::__rust_end_short_backtrace
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:168:18
8: rust_begin_unwind
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
9: core::panicking::panic_fmt
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
10: <project::lsp_store::ProjectLspAdapterDelegate>::new
at /Users/thorstenball/work/zed/crates/project/src/lsp_store.rs:6332:13
11: assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}::{closure#1}
at /Users/thorstenball/work/zed/crates/assistant/src/assistant_panel.rs:5159:16
12: <gpui::app::AppContext as gpui::Context>::update_model::<project::lsp_store::LspStore, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}::{closure#1}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1365:26
13: <gpui::app::AppContext>::update::<core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, <gpui::app::AppContext as gpui::Context>::update_model<project::lsp_store::LspStore, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}::{closure#1}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:362:22
14: <gpui::app::AppContext as gpui::Context>::update_model::<project::lsp_store::LspStore, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}::{closure#1}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1363:9
15: <gpui::app::model_context::ModelContext<project::Project> as gpui::Context>::update_model::<project::lsp_store::LspStore, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}::{closure#1}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/model_context.rs:250:9
16: <gpui::app::entity_map::Model<project::lsp_store::LspStore>>::update::<gpui::app::model_context::ModelContext<project::Project>, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}::{closure#1}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:422:9
17: assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}
at /Users/thorstenball/work/zed/crates/assistant/src/assistant_panel.rs:5158:9
18: <gpui::app::AppContext as gpui::Context>::update_model::<project::Project, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1365:26
19: <gpui::app::AppContext>::update::<core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, <gpui::app::AppContext as gpui::Context>::update_model<project::Project, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:362:22
20: <gpui::app::AppContext as gpui::Context>::update_model::<project::Project, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1363:9
21: <gpui::app::entity_map::Model<project::Project>>::update::<gpui::app::AppContext, core::result::Result<alloc::sync::Arc<dyn language::LspAdapterDelegate>, anyhow::Error>, assistant::assistant_panel::make_lsp_adapter_delegate::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:422:9
22: assistant::assistant_panel::make_lsp_adapter_delegate
at /Users/thorstenball/work/zed/crates/assistant/src/assistant_panel.rs:5152:5
23: <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}
at /Users/thorstenball/work/zed/crates/assistant/src/assistant_panel.rs:960:48
24: <gpui:🪟:WindowContext as gpui::VisualContext>::update_view::<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3940:22
25: <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view::<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/app/async_context.rs:387:35
26: <gpui::app::AppContext as gpui::Context>::update_window::<core::result::Result<(), anyhow::Error>, <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>::{closure#0}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1396:26
27: <gpui::app::AppContext>::update::<core::result::Result<core::result::Result<(), anyhow::Error>, anyhow::Error>, <gpui::app::AppContext as gpui::Context>::update_window<core::result::Result<(), anyhow::Error>, <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:362:22
28: <gpui::app::AppContext as gpui::Context>::update_window::<core::result::Result<(), anyhow::Error>, <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1387:9
29: <gpui::app::async_context::AsyncAppContext as gpui::Context>::update_window::<core::result::Result<(), anyhow::Error>, <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/async_context.rs:91:9
30: <gpui::app::async_context::AsyncWindowContext as gpui::Context>::update_window::<core::result::Result<(), anyhow::Error>, <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/async_context.rs:354:9
31: <gpui:🪟:AnyWindowHandle>::update::<gpui::app::async_context::AsyncWindowContext, core::result::Result<(), anyhow::Error>, <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4800:9
32: <gpui::app::async_context::AsyncWindowContext as gpui::VisualContext>::update_view::<assistant::assistant_panel::AssistantPanel, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/async_context.rs:386:9
33: <gpui::view::View<assistant::assistant_panel::AssistantPanel>>::update::<gpui::app::async_context::AsyncWindowContext, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:76:9
34: <gpui::view::WeakView<assistant::assistant_panel::AssistantPanel>>::update::<gpui::app::async_context::AsyncWindowContext, core::result::Result<(), anyhow::Error>, <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:192:12
35: <assistant::assistant_panel::AssistantPanel>::new_context::{closure#1}::{closure#0}
at /Users/thorstenball/work/zed/crates/assistant/src/assistant_panel.rs:957:17
36: <core::pin::Pin<alloc::boxed::Box<dyn core::future::future::Future<Output = core::result::Result<(), anyhow::Error>>>> as core::future::future::Future>::poll
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/future/future.rs:123:9
37: <<async_task::runnable::Builder<_>>::spawn_local::Checked<core::pin::Pin<alloc::boxed::Box<dyn core::future::future::Future<Output = core::result::Result<(), anyhow::Error>>>>> as core::future::future::Future>::poll
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.1/src/runnable.rs:455:26
38: <async_task::raw::RawTask<<async_task::runnable::Builder<_>>::spawn_local::Checked<core::pin::Pin<alloc::boxed::Box<dyn core::future::future::Future<Output = core::result::Result<(), anyhow::Error>>>>>, core::result::Result<(), anyhow::Error>, <gpui::executor::ForegroundExecutor>::spawn::inner<core::result::Result<(), anyhow::Error>>::{closure#0}, ()>>::run
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.1/src/raw.rs:557:17
39: <async_task::runnable::Runnable>::run
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-task-4.7.1/src/runnable.rs:781:18
40: gpui::platform::mac::dispatcher::trampoline
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/dispatcher.rs:106:5
41: <unknown>
42: <unknown>
43: <unknown>
44: <unknown>
45: <unknown>
46: <unknown>
47: <unknown>
48: <unknown>
49: <unknown>
50: <unknown>
51: <unknown>
52: <unknown>
53: <() as objc::message::MessageArguments>::invoke::<()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:128:17
54: objc::message::platform::send_unverified::<objc::runtime::Object, (), ()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/apple/mod.rs:27:9
55: objc::message::send_message::<objc::runtime::Object, (), ()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:178:5
<*mut objc::runtime::Object as cocoa::appkit::NSApplication>::run
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cocoa-0.26.0/src/appkit.rs:628:9
56: <gpui::platform::mac::platform::MacPlatform as gpui::platform::Platform>::run
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/platform.rs:427:13
57: <gpui::app::App>::run::<zed::main::{closure#3}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:159:9
58: zed::main
at /Users/thorstenball/work/zed/crates/zed/src/main.rs:439:5
59: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
60: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/backtrace.rs:152:18
61: std::rt::lang_start::<()>::{closure#0}
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/rt.rs:162:18
62: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:284:13
std::panicking
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:557:40
std::panicking::try
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:521:19
std::panic::catch_unwind
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panic.rs:350:14
std::rt::lang_start_internal::{{closure}}
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/rt.rs:141:48
std::panicking::try::do_call
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:557:40
std::panicking::try
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:521:19
std::panic::catch_unwind
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panic.rs:350:14
std::rt::lang_start_internal
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/rt.rs:141:20
63: std::rt::lang_start::<()>
at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/rt.rs:161:17
64: _main
```
Closes #ISSUE
Release Notes:
- Added/Fixed/Improved ...
Optionally, include screenshots / media showcasing your addition that
can be included in the release notes.
### Or...
Closes #ISSUE
Release Notes:
- N/A
Co-authored-by: Bennet <bennet@zed.dev>
This PR moves the local, remote, and ssh components of the LSP store
into their own types.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Conrad <conrad@zed.dev>
Currently, had done the function for support included and excluded
history navigate, but the code is more duplicate, I will dive into find
better method to decrease the duplicate code.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
This is a refactor to prepare for adding LSP support in SSH remote
projects.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
This PR reverts #17173, as it introduced a segfault when opening any
Gleam project and the language server starts up.
This reverts commit a850731b0e.
Release Notes:
- N/A
Context: https://x.com/fasterthanlime/status/1819120238228570598
Up to this PR:
- We were not watching paths outside of a worktree when language server
requested it.
- We expected GlobPattern used for file watching to be always rooted at
the worktree root.
'1 mattered for observing global files (e.g. global RA config) and both
points had impact on "monorepos".
Let's picture the following scenario:
You're working on a Rust project that has two crates: bin and lib crate:
```
my-rust-project/
bin-crate/
lib-crate/
```
Up to this PR, making changes like changing field visibility in
lib-crate **was not reflected** in bin-crate until RA was restarted. RA
for bin-crate asked us to watch lib-crate. Now, depending on if you had
this project open as:
- a project with one worktree rooted at my-rust-project:
- due to '2, we never noticed that we have to notify RA instance for
bin-crate about changes in lib-crate.
- a project with two worktrees (bin-crate and lib-crate):
- due to '1 (as lib-crate is not within bin-crate's worktree), we once
again missed the fact that we have to watch for changes in lib-crate.
This PR solves this by introducing a side-channel - we just store fs
watchers for abs paths at the Project level. Worktree changes handling
is left relatively untouched - as it's used for other changes besides
LSP change notifying, I've figured to better leave it as is, as right
now we have 1 worktree change watcher; if we were to change it, we'd
have `(language server) + 1` watchers per worktree, which seems.. pretty
horrid.
What's the end effect? At the very least fasterthanlime should be a tad
happier; in reality though, I expect it to have some impact on LS
reliability in monorepo setups.
TODO
- [x] Wire through FileChangeType into `fs::watch` interface.
Release Notes:
- Improved language server reliability in multi-worktree projects and
monorepo. We now notify the language server more reliably about which
files have changed.
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>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Co-Authored-By: Nate <nate@zed.dev>
Closes#15606Closes#13515
Release Notes:
- Fixes `-` being considered a word character for selections in some
languages
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Nate <nate@zed.dev>
This changes the Zed CLI `zed` to pass along the environment to the Zed
project that it opens (if it opens a new one).
In projects, this CLI environment will now take precedence over any
environment that's acquired by running a login shell in a projects
folder.
The result is that `zed my/folder` now always behaves as if one would
run `zed --foreground` without any previous Zed version running.
Closes#7894Closes#16293
Related issues:
- It fixes the issue described in here:
https://github.com/zed-industries/zed/issues/4977#issuecomment-2305272027
Release Notes:
- Improved the Zed CLI `zed` to pass along the environment as it was on
the CLI to the opened Zed project. That environment is then used when
opening new terminals, spawning tasks, or language servers.
Specifically:
- If Zed was started via `zed my-folder`, a terminal spawned with
`workspace: new terminal` will inherit these environment variables that
existed on the CLI
- Specific language servers that allow looking up the language server
binary in the environments `$PATH` (such as `gopls`, `zls`,
`rust-analyzer` if configured, ...) will look up the language server
binary in the CLI environment too and use that environment when starting
the process.
- Language servers that are _not_ found in the CLI environment (or
configured to not be found in there), will be spawned with the CLI
environment in case that's set. That means users can do something like
`RA_LOG=info zed .` and it will be picked up the rust-analyzer that was
spawned.
Demo/explanation:
https://github.com/user-attachments/assets/455905cc-8b7c-4fc4-b98a-7e027d97cdfa
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 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>
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
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
Allows language server logs to be published prior to the completion of
the initialize request. OmniSharp is one example of an LSP that
publishes (many) messages prior to the initialization response, and this
completely floods the Zed logs.
Also adds level filtering as demonstrated below. Again, this is due to
my experience with the massive amount of log messages that OmniSharp
publishes.
Release Notes:
- Added level filtering to language server logs
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Release Notes:
- vim: Added `gf` command to open files under the cursor.
- Filenames can now be `cmd`/`ctrl`-clicked, which opens them.
TODOs:
- [x] `main_test.go` <-- works
- [x] `./my-pkg/my_pkg.go` <-- works
- [x] `../go.mod` <-- works
- [x] `my-pkg/my_pkg.go` <-- works
- [x] `my-pkg/subpkg/subpkg_test.go` <-- works
- [x] `file\ with\ space\ in\ it.txt` <-- works
- [x] `"file\ with\ space\ in\ it.txt"` <-- works
- [x] `"main_test.go"` <-- works
- [x] `/Users/thorstenball/.vimrc` <-- works, but only locally
- [x] `~/.vimrc` <--works, but only locally
- [x] Get it working over collab
- [x] Get hover links working
Demo:
https://github.com/user-attachments/assets/26af7f3b-c392-4aaf-849a-95d6c3b00067
Collab demo:
https://github.com/user-attachments/assets/272598bd-0e82-4556-8f9c-ba53d3a95682
Release Notes:
- Added switch source/header action for clangd language server (fixes
[#12801](https://github.com/zed-industries/zed/issues/12801)).
Note: I'm new to both rust and this codebase. I started my
implementation by copying how rust analyzer's "expand macro" LSP
extension is implemented. I don't yet understand some of the code I
copied (mostly the way to get the `server_to_query` in `clangd_ext.rs`
and the whole proto implementation).
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
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:
- Makes slash commands easier to compose by adding a concept,
`CompletionIntent`. When using `tab` on a completion in the assistant
panel, that completion item will be expanded but the associated command
will not be run. Using `enter` will still either run the completion item
or continue command composition as before.
- Fixes a bug where running `/diagnostics` on a project with no
diagnostics will delete the entire command, rather than rendering an
empty header.
- Improves the autocomplete rendering for files, showing when
directories are selected and re-arranging the results to have the file
name or trailing directory show first.
<img width="642" alt="Screenshot 2024-08-13 at 8 12 43 PM"
src="https://github.com/user-attachments/assets/97c96cd2-741f-4f15-ad03-7cf78129a71c">
Release Notes:
- N/A
Adds support for [Goto
Declaration](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_declaration)
LSP command.
I am particularly interested in [this for Rust
projects](https://rust-analyzer.github.io/manual.html#go-to-declaration),
to be able to navigate to the place where a trait method is declared,
coming from a trait method implementation.
I noticed this was something I could do in VSCode before, but was
somehow missing is Zed. Thanks to the already existing infrastructure
for Goto Definition, I just followed and copy-paste-adapted it for Goto
Declaration.
As a bonus, I added `ctrl-F12` and `alt-ctrl-F12` as default macOS
keybindings for `GoToDeclaration` and `GoToDeclarationSplit`,
respectively. They are not keybindings from another editor, but I
figured they made sense to be grouped along with the other *F12
commands.
### Release Notes:
- Added "Go to declaration" editor action.
- vim: Breaking change to keybindings after introduction of the `Go to
declaration` editor action. The new keybindings are the following (and
can be found [here](https://zed.dev/docs/vim), alongside the other key
bindings):
- `g d` - Go to definition
- `g D` - Go to declaration
- `g y` - Go to type definition
- `g I` - Go to implementation
https://github.com/user-attachments/assets/ee5c10a8-94f0-4e50-afbb-6f71db540c1b
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
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 PR updates how we determine the "primary" language server for a
buffer to make it respect the order specified by the `language_servers`
setting.
Previously we were relying on the language servers to be registered in
the right order in order to select the primary one effectively.
However, in my testing I observed some cases where a native language
server (e.g., `tailwindcss-language-server`) could end up first in the
list of language servers despite not being first in the
`language_servers` setting.
While this wasn't a problem for the Tailwind or ESLint language servers
on account of them being defined natively with the designation of
"secondary" language servers, this could cause problems with
extension-based language servers.
To remedy this, every time we start up language servers we reorder the
list of language servers for a given language to reflect the order in
the `language_servers` setting. This ordering then allows us to treat
the first language server in the list as the "primary" one.
Related issues:
- https://github.com/zed-industries/zed/issues/15023
- https://github.com/zed-industries/zed/issues/15279
Release Notes:
- The ordering of language servers will now respect the order in the
`language_servers` setting.
- The first language server in this list will be used as the primary
language server.
We were reporting file count as worktree entry count, which led to us
missing some of the entries in /file command completion.
/cc @bennetbo
The other components that used `PathMatchCandidateSet` are
`/diagnostics` and file finder. File finder is unaffected, as it used
`Candidates::Files` - thus previously reported count was correct for it;
`/diagnostics` were using `::Entries` as well, so it could miss entries
just like `/files`.
Release Notes:
- Fixed /file and /diagnostics slash commands omitting entries in it's
completions menu.
This also rolls back the `TerminalWorkDir` abstraction I added for the
original remoting, and tidies up the terminal creation code to be clear
about whether we're creating a task *or* a terminal. The previous logic
was a little muddy because it assumed we could be doing both at the same
time (which was not true).
Release Notes:
- remoting alpha: Removed the ability to specify `gh cs ssh` or `gcloud
compute ssh` etc. See https://zed.dev/docs/remote-development for
alternatives.
- remoting alpha: Added support for terminal and tasks to new
experimental ssh remoting
This fixes#12125 and addresses what's described in here:
-
https://github.com/zed-industries/zed/issues/4977#issuecomment-2162094388
Before the changes in this PR, when running tasks, they inherited the
Zed process environment, but that might not be the process environment
that you'd get if you `cd` into a project directory.
We already ran into that problem with language servers and we fixed it
by loading the shell environment in the context of a projects root
directory and then passing that to the language servers when starting
them (or when looking for their binaries).
What the change here does is to add the behavior for tasks too: we use
the project-environment as the base environment with which to spawn
tasks. Everything else still works the same, except that the base env is
different.
Release Notes:
- Improved the environment-variable detection when running tasks so that
tasks can now access environment variables as if the task had been
spawned in a terminal that `cd`ed into a project directory. That means
environment variables set by `direnv`/`asdf`/`mise` and other tools are
now picked up.
([#12125](https://github.com/zed-industries/zed/issues/12125)).
Demo:
https://github.com/user-attachments/assets/8bfcc98f-0f9b-4439-b0d9-298aef1a3efe
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 related to #15023 where we have the running Rubocop LSP that
provides diagnostics and formatting capabilities. Rubocop LSP sends its
capabilities
back to Zed without support for "textDocument/definition" request, Zed
actually does not check that and sends a request to Rubocop that results
in the server error "Unsupported method: textDocument/definition".
The fix here is related to
https://github.com/zed-industries/zed/pull/14666
Release Notes:
- N/A
This adds support for detecting line comments in the
[Jupytext](https://jupytext.readthedocs.io/) format. When line comments
such as `# %%` is present, invoking `repl: run` will evaluate the code
between these line comments as a unit.
/cc @rgbkrk
```py
# %%
# This is my first block
print(1)
print(2)
# %%
# This is my second block
print(3)
```
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Thorsten <thorsten@zed.dev>
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Fixes#4822
- [x] Release note
- [ ] Surface formatting errors via a toast
- [x] Doc updates
- [x] Have "language-server" accept an optional name of the server.
Release Notes:
- `format` and `format_on_save` now accept an array of formatting
actions to run.
- `language_server` formatter option now accepts the name of a language
server to use (e.g. `{"language_server": {"name: "ruff"}}`); when not
specified, a primary language server is used.
---------
Co-authored-by: Thorsten <thorsten@zed.dev>
Per the LSP spec, we should pass .data field of diagnostics into code
action request:
```
/**
* A data entry field that is preserved between a
* `textDocument/publishDiagnostics` notification and
* `textDocument/codeAction` request. *
* @since 3.16.0 */ data?: LSPAny;
```
Release Notes:
- Fixed rare cases where a code action triggered by diagnostic may not
be available for use.
This is a first step towards allowing you to edit remote projects
directly over SSH. We'll start with a pretty bare-bones feature set, and
incrementally add further features.
### Todo
Distribution
* [x] Build nightly releases of `zed-remote-server` binaries
* [x] linux (arm + x86)
* [x] mac (arm + x86)
* [x] Build stable + preview releases of `zed-remote-server`
* [x] download and cache remote server binaries as needed when opening
ssh project
* [x] ensure server has the latest version of the binary
Auth
* [x] allow specifying password at the command line
* [x] auth via ssh keys
* [x] UI password prompt
Features
* [x] upload remote server binary to server automatically
* [x] opening directories
* [x] tracking file system updates
* [x] opening, editing, saving buffers
* [ ] file operations (rename, delete, create)
* [ ] git diffs
* [ ] project search
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Note that this shouldn't have any visible user-facing behavior yet. The
feature is incomplete but we wanna merge early to avoid a long-running
branch.
Release Notes:
- N/A
---------
Co-authored-by: Nathan <nathan@zed.dev>
This is a follow-up to #14666 in which I noticed that we don't need that
additional check, since each request will check whether it's supported
via the call to `check_capabilities` before sending the request.
Release Notes:
- N/A
This fixes https://github.com/zed-industries/zed/issues/13633 by not
sending `source.organizeImports` to the ESLint language server anymore.
Turns out that ESLint tells us through its capabilities that it doesn't
support that code action kind, but we ignored that.
What this code does is to check whether a given server supports specific
code action kinds.
It does this in two places:
1. When constructing the request: we now filter down the list of
requested `kinds`, in case we can do so. If we can't filter down the
list, we keep the previous behavior of sending the
`language_server.code_action_kinds()`
2. Before sending the request: we now check whether the server even
supports sending the request.
This fixes the issue by only sending actions to servers that support it.
I tested this with various language servers and setups and everything
still works (or works better). But of course there are a ton of
different combinations of language servers and code actions and file
types, so I couldn't test them all.
Release Notes:
- Fix ESLint language server adding comments on save if the
`source.organizeImports` code action was used on save. Zed now filters
out code actions sent to the language servers by checking whether they
are supported first.
([#13633](https://github.com/zed-industries/zed/issues/13633)).
This adds the ability for Zed to restore unsaved buffers on restart. The
user is no longer prompted to save/discard/cancel when trying to close a
Zed window with dirty buffers in it. Instead those dirty buffers are
stored and restored on restart.
It does this by saving the contents of dirty buffers to the internal
SQLite database in which Zed stores other data too. On restart, if there
are dirty buffers in the database, they are restored.
On certain events (buffer changed, file saved, ...) Zed will serialize
these buffers, throttled to a 100ms, so that we don't overload the
machine by saving on every keystroke. When Zed quits, it waits until all
the buffers are serialized.
### Current limitations
- It does not persist undo-history (right now we don't persist/restore
undo-history regardless of dirty buffers or not)
- It does not restore buffers in windows without projects/worktrees.
Example: if you open a new window with `cmd-shift-n` and type something
in a buffer, this will _not_ be stored and you will be asked whether to
save/discard on quit. In the future, we want to fix this by also
restoring windows without projects/worktrees.
### Demo
https://github.com/user-attachments/assets/45c63237-8848-471f-8575-ac05496bba19
### Related tickets
I'm unsure about closing them, without also fixing the 2nd limitation:
restoring of worktree-less windows. So let's wait until that.
- https://github.com/zed-industries/zed/issues/4985
- https://github.com/zed-industries/zed/issues/4683
### Note on performance
- Serializing editing buffer (asynchronously on background thread) with
500k lines takes ~200ms on M3 Max. That's an extreme case and that
performance seems acceptable.
Release Notes:
- Added automatic restoring of unsaved buffers. Zed can now be closed
even if there are unsaved changes in buffers. One current limitation is
that this only works when having projects open, not single files or
empty windows with unsaved buffers. The feature can be turned off by
setting `{"session": {"restore_unsaved_buffers": false}}`.
---------
Co-authored-by: Bennet <bennet@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Release Notes:
- linux: Added a fallback Open picker for when XDG is not working
- Added a new setting `use_system_path_prompts` (default true) that can
be disabled to use Zed's builtin keyboard-driven prompts.
---------
Co-authored-by: Max <max@zed.dev>
Provide a current, broken state as an experimental way to browse
diagnostics.
The diagnostics are grouped by lines and reduced into a block that, in
case of multiple diagnostics per line, could be toggled back and forth
to show more diagnostics on the line.
Use `grouped_diagnostics::Deploy` to show the panel.
Issues remaining:
* panic on warnings toggle due to incorrect excerpt manipulation
* badly styled blocks
* no key bindings to navigate between blocks and toggle them
* overall odd usability gains for certain groups of people
Due to all above, the thing is feature-gated and not exposed to regular
people.
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/12909
* Fully preserve LSP data when sending it via collab, and only strip it
on the client.
* Avoid extra custom request handlers, and extend multi LSP server query
protocol instead.
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
I don't intend fully on getting this merged, this is just an experiment
on using `direnv` directly without relying on shell-specific behaviours.
It works though, so this finally closes#8633
Release Notes:
- Fixed nushell not picking up `direnv` environments by directly
interfacing with it using `direnv export`
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
TODO:
- [ ] File a PR with Yarn to add Zed to the list of supported IDEs.
Fixes: https://github.com/zed-industries/zed/issues/10107
Fixes: https://github.com/zed-industries/zed/issues/13706
Release Notes:
- Improved experience in projects using Yarn. Run `yarn dlx
@yarnpkg/sdks base` in the root of your project in order to elevate your
experience.
---------
Co-authored-by: Saurabh <79586784+m4saurabh@users.noreply.github.com>
The biggest hurdle turned out to be use of `Arc<Language>` in maps, as
`clippy::mutable_key_type` started triggering on it (due to - I suppose
- internal mutability on `HighlightMap`?). I switched over to using
`LanguageId` as the key type in some of the callsites, as that's what
`Language` uses anyways for it's hash/eq, though I've still had to
suppress the lint outside of language crate.
/cc @maxdeviant , le clippy guru.
Release Notes:
- N/A
This pull request introduces collaboration for the assistant panel by
turning `Context` into a CRDT. `ContextStore` is responsible for sending
and applying operations, as well as synchronizing missed changes while
the connection was lost.
Contexts are shared on a per-project basis, and only the host can share
them for now. Shared contexts can be accessed via the `History` tab in
the assistant panel.
<img width="1819" alt="image"
src="https://github.com/zed-industries/zed/assets/482957/c7ae46d2-cde3-4b03-b74a-6e9b1555c154">
Please note that this doesn't implement following yet, which is
scheduled for a subsequent pull request.
Release Notes:
- N/A
Release Notes:
- Move snippet support into core editor experience, marking the official
extension as deprecated. Snippets now show up in any buffer (including
plain text buffers).
Context:
@bennetbo spotted a regression in handling of `cargo run` task in zed
repo following a merge of #13658. We've started invoking `cargo run`
from the folder of an active file whereas previously we did it from the
workspace root. We brainstormed few solutions that involved adding a
separate task that gets invoked at a workspace level, but I realized
that a cleaner solution may be to finally add user-configured task
variables. This way, we can choose which crate to run by default at a
workspace level.
This has been originally brought up in the context of javascript tasks
in
https://github.com/zed-industries/zed/pull/12118#issuecomment-2129232114
Note that this is intended for internal use only for the time being.
/cc @RemcoSmitsDev we should be unblocked on having runner-dependant
tasks now.
Release notes:
- N/A
This PR replaces the `lazy_static!` usages in the `paths` crate with
`OnceLock` from the standard library.
This allows us to drop the `lazy_static` dependency from this crate.
The paths are now exposed as accessor functions that reference a private
static value.
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 PR extracts the definition of the various Zed paths out of `util`
and into a new `paths` crate.
`util` is for generic utils, while these paths are Zed-specific. For
instance, `gpui` depends on `util`, and it shouldn't have knowledge of
these paths, since they are only used by Zed.
Release Notes:
- N/A
I previously put this logic directly into `project.rs`, but it doesn't
feel good to pollute that code with telemetry logic, so I've moved it
over to `telemetry.rs`.
Release Notes:
- N/A
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
Fixes#12920
VTSLS does not mark snippet completions as such in the initial
completion response - not until we resolve them; however, we do not
touch initial contents of completion during resolution, which led to us
not treating a snippet as such.
Release Notes:
- Fixed snippet completions sometimes being treated as plain text
completions when using VTSLS
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 adds support for [linked editing of
ranges](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_linkedEditingRange),
which in short means that editing one part of a file can now change
related parts in that same file. Think of automatically renaming
HTML/TSX closing tags when the opening one is changed.
TODO:
- [x] proto changes
- [x] Allow disabling linked editing ranges on a per language basis.
Fixes#4535
Release Notes:
- Added support for linked editing ranges LSP request. Editing opening
tags in HTML/TSX files (with vtsls) performs the same edit on the
closing tag as well (and vice versa). It can be turned off on a language-by-language basis with the following setting:
```
"languages": {
"HTML": {
"linked_edits": true
},
}
```
---------
Co-authored-by: Bennet <bennet@zed.dev>
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
Release Notes:
- Added support for looking up the `rust-analyzer` binary in `$PATH`. This allows using such tools as `asdf` and nix to configure per-folder rust installations. To enable this behavior, use the `path_lookup` key when configuring the `rust-analyzer` `binary`: `{"lsp": {"rust-analyzer": {"binary": {"path_lookup": true }}}}`.
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))
Previously, each git `Repository` object was held inside of a mutex.
This was needed because libgit2's Repository object is (as one would
expect) not thread safe. But now, the two longest-running git operations
that Zed performs, (`status` and `blame`) do not use libgit2 - they
invoke the `git` executable. For these operations, it's not necessary to
hold a lock on the repository.
In this PR, I've moved our mutex usage so that it only wraps the libgit2
calls, not our `git` subprocess spawns. The main user-facing impact of
this is that the UI is much more responsive when initially opening a
project with a very large git repository (e.g. `chromium`, `webkit`,
`linux`).
Release Notes:
- Improved Zed's responsiveness when initially opening a project
containing a very large git repository.
- Confirming a completion now runs the command immediately
- Hitting `enter` on a line with a command now runs it
- The output of commands gets folded away and replaced with a custom
placeholder
- Eliminated ambient context
<img width="1588" alt="image"
src="https://github.com/zed-industries/zed/assets/482957/b1927a45-52d6-4634-acc9-2ee539c1d89a">
Release Notes:
- N/A
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Fixes https://github.com/zed-industries/zed/issues/9575
Fixes https://github.com/zed-industries/zed/issues/4294
### Problem
When a large git repository's `.git` folder changes (due to a `git
commit`, `git reset` etc), Zed needs to recompute the git status for
every file in that git repository. Part of computing the git status is
the *unstaged* part - the comparison between the content of the file and
the version in the git index. In a large git repository like `chromium`
or `linux`, this is inherently pretty slow.
Previously, we performed this git status all at once, and held a lock on
our `BackgroundScanner`'s state for the entire time. On my laptop, in
the `linux` repo, this would often take around 13 seconds.
When opening a file, Zed always refreshes the metadata for that file in
its in-memory snapshot of worktree. This is normally very fast, but if
another task is holding a lock on the `BackgroundScanner`, it blocks.
### Solution
I've restructured how Zed handles Git statuses, so that when a git
repository is updated, we recompute files' git statuses in fixed-sized
batches. In between these batches, the `BackgroundScanner` is free to
perform other work, so that file operations coming from the main thread
will still be responsive.
Release Notes:
- Fixed a bug that caused long delays in opening files right after
performing a commit in very large git repositories.
This PR adds initial support for defining slash commands for the
Assistant from extensions.
Slash commands are defined in an extension's `extension.toml`:
```toml
[slash_commands.gleam-project]
description = "Returns information about the current Gleam project."
requires_argument = false
```
and then executed via the `run_slash_command` method on the `Extension`
trait:
```rs
impl Extension for GleamExtension {
// ...
fn run_slash_command(
&self,
command: SlashCommand,
_argument: Option<String>,
worktree: &zed::Worktree,
) -> Result<Option<String>, String> {
match command.name.as_str() {
"gleam-project" => Ok(Some("Yayyy".to_string())),
command => Err(format!("unknown slash command: \"{command}\"")),
}
}
}
```
Release Notes:
- N/A
Release Notes:
- Added ZED_RELATIVE_FILE (path to current file relative to worktree
root) and ZED_DIRNAME (path to the directory containing current file)
task variables.
This PR changes the interface of ContextProvider, allowing it to inspect
*all* variables set so far during the process of building
`TaskVariables`. This makes it possible to capture e.g. an identifier in
tree-sitter query, process it and then export it as a task variable.
Notably, the list of variables includes captures prefixed with leading
underscore; they are removed after all calls to `build_context`, but it
makes it possible to capture something and then conditionally preserve
it (and perhaps modify it).
Release Notes:
- N/A
This fixes#4529 by allowing unsaved buffers to be formatted with
prettier.
Steps to do that:
1. Create a new buffer
2. Set language for the buffer (e.g.: `language selector: toggle` and
JSON)
3. In settings, set prettier parser for language (can't be inferred,
since we don't have filename) and allow formatting with prettier:
```json
{
"languages": {
"JSON": {
"prettier": {
"allowed": true,
"parser": "json"
}
}
}
}
```
4. Use `editor: format`
Release Notes:
- Added ability to format unsaved buffers with Prettier. Requirement is
to set a Prettier parser in the user settings. Example for JSON: `{
"languages": { "JSON": { "prettier": { "allowed": true, "parser": "json"
} } } }` ([#4529](https://github.com/zed-industries/zed/issues/4529)).
Demo:
https://github.com/zed-industries/zed/assets/1185253/d24e490b-2e2c-4a5d-95a8-fc8675523780
This fixes#10224 by handling `client/unregisterCapability` requests
that have a `workspace/didChangeWatchedFiles` method.
While debugging the issue, I found out that `gopls` seems to block
indefinitely when there's no reply to the `client/unregisterCapability`
request. Even an empty response would fix the issue.
Seems like gopls 15.x and later seem to handle nested subfolders well,
but do not handle unanswered requests.
Instead of replying with an empty response, I decided to change how we
handle file watching and keep a list of all registered paths so that we
can then unregister paths and recreate the glob patterns.
Release Notes:
- Fixed `gopls` not working correctly when the `go.mod` file was in a
subfolder and not the root folder of the project opened in Zed.
([#10224](https://github.com/zed-industries/zed/issues/10224)).
Fixes#5267
TODO:
- [x] Publish our fork of vscode-langservers-extracted on GH and wire
that through as a language server of choice for HTML extension.
- [x] Figure out how to prevent edits made by remote participants from
moving the cursor of a host.
Release Notes:
- Added support for autoclosing of HTML tags in local projects.
This fixes#10532 by properly making use of `itemDefaults.data` when
that is sent along next to completion `items`.
With this line here we tell the language server that we support `data`
in `itemDefaults`, but we actually never checked for it and never used
it:
a0d7ec9f8e/crates/lsp/src/lsp.rs (L653)
In the case of `tailwindcss-language-server` that means that most of the
items it returns (more than 10k items!) were missing the `data`
attribute, since the language server thought it can send it along in the
`itemDefaults` (because we advertised our capability to use it.)
When we then did a `completionItem/resolve`, we would not send a `data`
attribute along, which lead to an error on the
`tailwindcss-language-server` side and thus no documentation.
This PR also adds support for the other `itemDefaults` that could be
sent along and that we say we support:
a0d7ec9f8e/crates/lsp/src/lsp.rs (L650-L653)
`editRange` we handle separately, so this PR only adds the other 3.
Release Notes:
- Fixed documentation not showing up for completion items coming from
`tailwindcss-language-server`.
([#10532](https://github.com/zed-industries/zed/issues/10532)).
Demo:
https://github.com/zed-industries/zed/assets/1185253/bc5ea0b3-7d83-499f-a908-b0d2a1db8a41
Closes https://github.com/zed-industries/zed/issues/11517
* Removes forced prettier parser name for languages, making `auto`
command to run prettier on every file by default.
* Moves prettier configs away from plugin language declarations into
language settings
Release Notes:
- N/A
