(and any other LSP server in theory, if it exposes any LSP-ext endpoint
for the same)
Closes https://github.com/zed-industries/zed/issues/16160
* adds a way to disable tree-sitter tasks (the ones from the plugins,
enabled by default) with
```json5
"languages": {
"Rust": "tasks": {
"enabled": false
}
}
}
```
language settings
* adds a way to disable LSP tasks (the ones from the rust-analyzer
language server, enabled by default) with
```json5
"lsp": {
"rust-analyzer": {
"enable_lsp_tasks": false,
}
}
```
* adds rust-analyzer tasks into tasks modal and gutter:
<img width="1728" alt="modal"
src="https://github.com/user-attachments/assets/22b9cee1-4ffb-4c9e-b1f1-d01e80e72508"
/>
<img width="396" alt="gutter"
src="https://github.com/user-attachments/assets/bd818079-e247-4332-bdb5-1b7cb1cce768"
/>
Release Notes:
- Added tasks from rust-analyzer
We cannot compare versions and anchors between different `Buffer`s with
different `BufferId`s.
Release Notes:
- Fixed Zed panicking on editor reopen
Co-authored-by: Conrad Irwin <conrad@zed.dev>
Same as `editor::RestartLanguageServer`, now there's an
`editor::StopLanguageServer` action that stops all language servers,
related to the currently opened editor.
Opening another singleton editor with the same language or changing
selections in a multi buffer will bring the servers back up.
Release Notes:
- Added a way to temporarily stop LSP servers
---------
Co-authored-by: Michael Sloan <mgsloan@gmail.com>
Closes https://github.com/zed-industries/zed/issues/11626
Part of https://github.com/zed-industries/zed/issues/12853
`"restore_on_file_reopen": true` in workspace settings can now be used
to enable and disable editor data between file reopens in the same pane:
https://github.com/user-attachments/assets/8d938ee1-d854-42a8-bbc3-2a4e4d7d5933
The settings are generic and panes' data store can be extended for
further entities, beyond editors.
---------------
Impl details:
Currently, the project entry IDs seem to be stable across file reopens,
unlike BufferIds, so those were used.
Originally, the DB data was considered over in-memory one as editors
serialize their state anyway, but managing and exposing PaneIds out of
the DB is quite tedious and joining the DB data otherwise is not
possible.
Release Notes:
- Started to restore editor state on reopen
A readonly buffer built from a static `&str` output does not need rich
project-based capabilities, and leaking projects in global git panel
might be dangerous.
Also adds readonly capability to the buffer, as
`editor.set_read_only(true);` API is a separate thing.
Release Notes:
- N/A
Similar to how tasks are fetched via LSP, also queries for document's
code lens and filters the ones with the commands, supported in server
capabilities.
Whatever's left and applicable to the range given, is added to the
actions menu:
This way, Zed can get more actions to run, albeit neither r-a nor vtsls
seem to provide anything by default.
Currently, there are no plans to render code lens the way as in VSCode,
it's just the extra actions that are show in the menu.
------------------
As part of the attempts to use rust-analyzer LSP data about the
runnables, I've explored a way to get this data via standard LSP.
When particular experimental client capabilities are enabled (similar to
how clangd does this now), r-a starts to send back code lens with the
data needed to run a cargo command:
```
{"jsonrpc":"2.0","id":48,"result":{"range":{"start":{"line":0,"character":0},"end":{"line":98,"character":0}},"command":{"title":"▶︎ Run Tests","command":"rust-analyzer.runSingle","arguments":[{"label":"test-mod tests::ecparser","location":{"targetUri":"file:///Users/someonetoignore/work/ec4rs/src/tests/ecparser.rs","targetRange":{"start":{"line":0,"character":0},"end":{"line":98,"character":0}},"targetSelectionRange":{"start":{"line":0,"character":0},"end":{"line":98,"character":0}}},"kind":"cargo","args":{"environment":{"RUSTC_TOOLCHAIN":"/Users/someonetoignore/.rustup/toolchains/1.85-aarch64-apple-darwin"},"cwd":"/Users/someonetoignore/work/ec4rs","overrideCargo":null,"workspaceRoot":"/Users/someonetoignore/work/ec4rs","cargoArgs":["test","--package","ec4rs","--lib"],"executableArgs":["tests::ecparser","--show-output"]}}]}}}
```
This data is passed as is to VSCode task processor, registered in
https://github.com/rust-lang/rust-analyzer/blob/60cd01864a2d0d6e2231becee402ba063b59dfa1/editors/code/src/main.ts#L195
where it gets eventually executed as a VSCode's task, all handled by the
r-a's extension code.
rust-analyzer does not declare server capabilities for such tasks, and
has no `workspace/executeCommand` handle, and Zed needs an interactive
terminal output during the test runs, so we cannot ask rust-analyzer
more than these descriptions.
Given that Zed needs experimental capabilities set to get these lens:
https://github.com/rust-lang/rust-analyzer/blob/60cd01864a2d0d6e2231becee402ba063b59dfa1/editors/code/src/client.ts#L318-L327
and that the lens may contain other odd tasks (e.g. docs opening or
references lookup), a protocol extension to get runnables looks more
preferred than lens:
https://rust-analyzer.github.io/book/contributing/lsp-extensions.html#runnables
This PR does not include any work on this direction, limiting to the
general code lens support.
As a proof of concept, it's possible to get the lens and even attempt to
run it, to no avail:
Release Notes:
- Used `textDocument/codeLens` data in the actions menu when applicable
Follow-up of https://github.com/zed-industries/zed/pull/26410
* Extract word completions into their own, `editor::ShowWordCompletions`
action so those could be triggered independently of completions
* Assign `ctrl-shift-space` binding to this new action
* Still keep words returned along the completions as in the original PR,
but:
* Tone down regular completions' fallback logic, skip words when the
language server responds with empty list of completions, but keep on
adding words if nothing or an error were returned instead
* Adjust the defaults to wait for LSP completions infinitely
* Skip "words" with digits such as `0_usize` or `2.f32` from completion
items, unless a completion query has digits in it
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/26431
Follow-up of https://github.com/zed-industries/zed/pull/26174
`path_with_position.path.strip_prefix(&worktree_root)` used in the PR is
wrong for cases of single-file worktrees, where it will return empty
paths that will result in incorrect project and FS entries accessed.
Release Notes:
- Fixed goto single file worktrees during terminal cmd-clicks
Closes https://github.com/zed-industries/zed/issues/4957https://github.com/user-attachments/assets/ff491378-376d-48ec-b552-6cc80f74200b
Adds `"completions"` language settings section, to configure LSP and
word completions per language.
Word-based completions may be turned on never, always (returned along
with the LSP ones), and as a fallback if no LSP completion items were
returned.
Future work:
* words are matched with the same fuzzy matching code that the rest of
the completions are
This might worsen the completion menu's usability even more, and will
require work on better completion sorting.
* completion entries currently have no icons or other ways to indicate
those are coming from LSP or from word search, or from something else
* we may work with language scopes more intelligently, group words by
them and distinguish during completions
Release Notes:
- Supported word-based completions
---------
Co-authored-by: Max Brunsfeld <max@zed.dev>
Disables https://github.com/zed-industries/zed/pull/26146 until a better
way to add diagnostics is found.
Overall, the PR had made changes that are worth keeping instead of
reverting, such as finally extracting out r-a's language server logic
into an `_ext.rs` file.
Release Notes:
- N/A
A preparation for https://github.com/zed-industries/zed/issues/4957 that
pushes all LSP-related data out from the basic completion item, so that
it's possible to create completion items without any trace of LSP
clearly.
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/25701
Reworks the way cmd-click is handled:
* first, all worktree entries are checked for existence
This allows more fine-grained lookup of entries that are in the
worktree, but their path in the terminal is not "full": in case neither
`cwd` no worktree's root + that temrinal paths form a valid path
(https://github.com/zed-industries/zed/issues/25701)
The worktrees are sorted by "the most close to cwd first" so such files
are attempted to resolved in the most specific worktree.
This also fixes no cmd-click working in the remote ssh.
* second, only if the client is local, do the FS checks to find
non-indexed files
Release Notes:
- Improved cmd-click in terminal to find more paths
Proper version of https://github.com/zed-industries/zed/pull/25425
When https://github.com/zed-industries/zed/pull/24857 returned font
updates on settings changes, settings values, not in-memory ones should
be compared.
This PR returns back the logic finally, and changes it to explicitly
track the settings values, not the in-memory ones.
Also adds the same tracking for UI font changes, which had never been
tracked before.
Release Notes:
- Fixed font sizes not reacting on settings change
Closes https://github.com/zed-industries/zed/issues/25865
Closes https://github.com/zed-industries/zed/pull/25915
In the issue, Zed had caused `.git/lfs/tmp/466102258`-like files to
appear in the directory, which lead to background FS event listener to
handle this as an update, incrementing snapshot's `scan_id`, which lead
to git status rescan, which caused another increment to `status_scan_id`
— incrementing either of the IDs causes the related repo data to be
considered "changed:
https://github.com/zed-industries/zed/blob/41b45eaba798a56e596857fa497c862050788bc7/crates/worktree/src/worktree.rs#L1590-L1605
hence propagating events to the other parts of the system (e.g. git
blame, which was also active in the issue's case)
```
[2025-03-01T20:01:08+01:00 DEBUG worktree] ignoring event ".git/lfs/tmp/466102258" within unloaded directory
[2025-03-01T20:01:08+01:00 DEBUG worktree] received fs events []
[2025-03-01T20:01:08+01:00 DEBUG worktree] reloading repositories: ["/Users/alex/dev/monorepo/.git"]
[2025-03-01T20:01:08+01:00 DEBUG editor::git::blame] Status of git repositories updated. Regenerating blame data...
[2025-03-01T20:01:08+01:00 DEBUG editor::git::blame] Status of git repositories updated. Regenerating blame data...
[2025-03-01T20:01:08+01:00 DEBUG editor::git::blame] Status of git repositories updated. Regenerating blame data...
```
Due to repo update events sent, another `.git/lfs/tmp/` entry is
created, things start over...
The PR fixes this by ignoring any `.git/lfs/` directory-related FS
events, as needed for the current git status update heuristics.
https://github.com/zed-industries/zed/pull/25915 tried to follow further
and `scan_id` and `status_scan_id` but we do not store all git state in
memory, e.g. head
https://github.com/zed-industries/zed/blob/e0060b92cc862c4d926652e1a01f0991ccb3a805/crates/editor/src/editor_tests.rs#L13686
as
[tests](https://github.com/zed-industries/zed/actions/runs/13631960559/job/38101504549?pr=25915)
show.
Release Notes:
- Improved `.git` scan heuristics
Follow-up of https://github.com/zed-industries/zed/pull/25766
Fixes the bugs found:
* modifier toggle not happening instantly due to `edit_debounce_ms`
considered
* hint update race that ignored the cache clear
Release Notes:
- N/A
https://github.com/zed-industries/zed/pull/25752 with fixes on top
* Ensures no flickering happens for all modifiers `: false` case
* Dismisses the toggled state on focus out
* Reworks cache state so that "enabled" and "toggled by modifiers" are
different states with their own lifecycle
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/25605
Previous PR made global tasks with `ZED_WORKTREE_ROOT` available for
"nothing open" scenario, this PR also gets all related worktree task
templates, using the centralized `TextContexts`' active worktree
detection.
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/22912
Reworks the task context infrastructure so that it's possible to have
multiple contexts at the same time, and stores all possible worktree
context there.
Task UI code is now falling back to the "active" worktree context, if
active item's context did not produce a resolved task.
Current code does not produce meaningful results for projects with
multiple worktrees to avoid ambiguity and design changes: instead of
resolving tasks per worktree context available, extra worktree context
is only used when resolving tasks from the same worktree.
Release Notes:
- Improved Zed tasks' `ZED_WORKTREE_ROOT` fallbacks
When migrating to gpui2,
https://github.com/zed-industries/zed/commit/588976d27a22bb36a5aac7e762b21e180a66a2f9#diff-a3da3181e4ab4f73aa1697d7b6dc0caa0c17b2a187fb83b076dfc0234ec91f54R21
removed the diagnostic style for "active but invalid" case: presumably,
it served as some sort of a cursor to show where to move on after the
diagnostics update, on the next `GoTo[Prev]Diagnostic` action call.
As this change went unchanged for some time, another approach is tested
now, to be more integrated with inline diagnostics: now, the active
state is cleared
Same as before this change, another `GoTo[Prev]Diagnostic` action call
will be needed to re-expand a new diagnostics, but this change makes
this expansion to happen after the cursor — before the change, Zed would
continue from the stale diagnostics.
Release Notes:
- Fixed active diagnostics becoming stale
Closes https://github.com/zed-industries/zed/issues/25413
As the issue points out well, themes do not need to alter any in-memory
state on load: that is done via settings file load.
Originally, it was introduced in
https://github.com/zed-industries/zed/pull/4064 and
https://github.com/zed-industries/zed/pull/24857 had restored that
behavior, which seems wrong to do.
Apart from removing that part, removes unnecessary methods and
emphasizes that in-memory state is the Buffer/UI size — no need to add
`Adjusted` there as the settings file presence is already enough.
Release Notes:
- Fixed theme selector resetting the buffer size
Follow-up of https://github.com/zed-industries/zed/pull/24857
Based on the feedback,
* made non-persisting font size change as a default in Zed keymaps
JetBrains IDEs seem to persist font size changes by default, hence left
to do so in Zed keymaps too
* fixed a bug with holding a binding to change the font size caused
flickering
Release Notes:
- N/A
Follow-up of https://github.com/zed-industries/zed/pull/24307
Brings back the PR and fixes the issue with the git status not
propagated, if computed too slow.
Now, git repo update
* waits in the background for all `scan_dir` repo status updates and
triggers another status update send afterwards
* ensures that the update sent is reported correctly (`scanning = true`)
if either FS or status scan is running still
* during worktree's git statuses updates, bumps `status_scan_id` to
ensure the repo update is reported to all subscribers
Release Notes:
- Improved project panel's speed in large projects
Closes https://github.com/zed-industries/zed/issues/23505
Now `zed::IncreaseBufferFontSize` (and all the same UI- and
Buffer-related settings) action is parameterized with `{ "persist": true
}` (default).
Using `"persist": false` brings back resizing behavior prior to
https://github.com/zed-industries/zed/pull/23265
Release Notes:
- Added a way to toggle font size without settings adjustments
Re-lands https://github.com/zed-industries/zed/pull/24446 with a more
appropriate fix
https://github.com/user-attachments/assets/45f665f0-473a-49bd-b013-b9d1bdb902bd
After activating 2nd diagnostics group, `find_map` code for next
diagnostics did not skip the previous group for the same place.
This time, instead of fiddling with the diagnostics group comparison,
the code splits the diagnostics by search place, looks up the active
group (if any) in both split parts, and selects the entries after the
group elements.
Release Notes:
- Fixed `editor::GoToDiagnostics` action stuck when multiple diagnostics
groups belong to the same place
Closes https://github.com/zed-industries/zed/issues/22993
Properly calculates depth and maintains worktree order, when displaying
multiple worktrees in the outline panel.
Release Notes:
- Fixed outline panel issues in a multi-worktree set-up
Closes https://github.com/zed-industries/zed/issues/24128
* removed unnecessary debounces when updating the panel data
* removed all "loading"-related messages to snow nothing when initial
data is loaded, thus reducing flickering
Release Notes:
- Improved outline panel initial update
https://github.com/user-attachments/assets/45f665f0-473a-49bd-b013-b9d1bdb902bd
After activating 2nd diagnostics group, `find_map` code for next
diagnostics did not skip the previous group for the same place.
Release Notes:
- Fixed `editor::GoToDiagnostics` action stuck when multiple diagnostics
groups belong to the same place
https://github.com/user-attachments/assets/200b88b8-249a-4841-97cd-fda8365efd00
Now all users in the collab/ssh session can edit the commit input
collaboratively, observing each others' changes live.
A real `.git/COMMIT_EDITMSG` file is opened, which automatically enables
its syntax highlight, but its original context is never used or saved on
disk — this way we avoid stale commit messages from previous commits
that git places there.
A caveat: previous version put some effort into preserving unfinished
commit messages on repo swtiches, but this version would not do that
— instead, it will be blank on startup, and use whatever
`.git/COMMIT_EDITMSG` contents on repo switch
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Follow-up of https://github.com/zed-industries/zed/pull/23869
* Retrieves user + email for collab project clients and use these when
such users commit
Same as in https://github.com/zed-industries/zed/pull/23329, "is it the
right user name and e-mail" and "how to override these" questions apply.
* If this data is unavailable, forbid committing to the remote client
* Forbid running related actions in git panel, if committing/writing is
not permitted
Release Notes:
- N/A
A preparation for collaborative commit message editing.
Before, almost any `.git`-contained file FS update, except
`.git/fsmonitor--daemon/cookies/**` caused git metadata rescan.
This included `index.lock` that was created after any git operation,
e.g. `git status`, which was unnecessary.
Collaborative editing aims to share `.git/COMMIT_EDITMSG` between
multiple users, so there are potentially multiple users editing the file
and causing excessive events.
The change makes worktree to ignore .git/COMMIT_EDITMSG`,
`.git/index.lock` and `.git/fsmonitor--daemon/**` paths and adjusts the
logic to be more extensible: there's much more files Zed can ignore and
still have its git metadata up to date.
Release Notes:
- N/A
Now both remote collab and ssh remote get entries shown and updated in
the git panel.
This seems to be quite a step towards remote git support, hence
submitting a PR.
Further steps: remove `get_local_repo` and allow getting the repo from
`Worktree`, not its local counterpart + have another, remote impl of the
`GitRepository` trait.
Release Notes:
- N/A
Kirill Bulatov
