These comments are inaccurate. Even if `convert_case` provided a way to
customize which boundaries were used (which is now does, it 0.7.1), they
would be removed from the string and replaced with the new boundary
character (`-`, `_`, ...), and we'd lose the ability to reconstruct the
text the way the author formatted it. This is not a hack, this is the
way we have to do it.
Release Notes:
- N/A
This adds support for LSPs that use the old rename flow which does not
first ask the LSP for the rename range and check that it is a valid
range to rename.
Closes#16663
Release Notes:
* Fixed rename symbols action when the language server does not have the
capability to prepare renames - such as `luau-lsp`.
Before this change it was using the same multibuffer point ranges in
every buffer, which only worked correctly for singleton buffers.
Release Notes:
- Fixed handling of selection ranges when formatting selections within a
multibuffer.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Closes#9656. Continuation of #9654, but with the addition of backwards
compatibility for the existing captures.
Release Notes:
- Improved Tree-sitter support with added compatibility for standard
injections captures
---------
Co-authored-by: Finn Evers <finn.evers@outlook.de>
Closes https://github.com/zed-industries/zed/issues/19214
Closes https://github.com/zed-industries/zed/pull/22443
Adds `resolved` property into Zed completion item data, to ensure we
resolve every completion item exactly once.
There are 2 paths for singplayer Zed, and corresponding 2 analogues for
multi player code, where resolve may happen:
* completions menu display & selection, that ends up using
`resolve_completions` in `lsp_store.rs`
* applying a completion menu entry, that ends up using
`apply_additional_edits_for_completion` in `lsp_store.rs`
Now, all local counterparts check `enabled` field before resolving and
set it to true afterwards, and reuse the same `resolve_completion_local`
method for resolving the items.
A logic for re-generating docs and item labels was moved out from the
`resolve_completion_local` method into a separate method, as
`apply_additional_edits_for_completion` does not need that, but needs
the rest of the logic for resolving.
During the extraction, I've noted that multiplayer clients are not
getting the item labels, regenerated after the resolve — as the Zed
protocol-based flow is not the exact copy of the local resolving.
To improve that, `resolve_completion_remote` needs to be adjusted, but
this change is omitted to avoid bloating the PR.
Release Notes:
- Fixed autocomplete inserting multiple imports
Leaving release notes as N/A because it had release notes in the past in
#21705
In #21286, documentation resolution was made more efficient by only
resolving the current completion. However, this meant that single line
documentation shown inline in the menu was missing until scrolled
to. This also meant that it would wait for navigation to resolve
completion docs, leading to lag for displaying documentation.
This change resolves this by attempting to fetch all the completions
that will be shown. It also mostly avoids re-resolving completions. It
intentionally re-resolves the current selection on navigation, as some
language servers will respond with more information later on.
Release Notes:
- N/A
If an inline completion isn't shown in a menu, we highlight text in the
editor as deleted.
But if it's shown in the menu, we didn't even show deleted text, which
makes it hard to understand what's going on.
This fixes it.

Release Notes:
- N/A
`CodeContextMenu` is always accessed on one thread, so only `Rc`s and
`Rc<RefCell<_>>` are needed. There should be tiny performance benefits
from this. The main benefit of this is that when seeing code accessing a
`RwLock` it would be reasonable to wonder whether it will block. The
only potential downside is the potential for panics due to overlapping
borrows of the RefCells. I think this is an acceptable risk because most
errors of this nature will be local or will be caught by clippy via the
check for holding a RefCell reference over an `await`.
Release Notes:
- N/A
This fixes#21837, where CompletionsMenu fuzzy match positions were
desynchronized from completion label text. The solution is to not mutate
`match_candidates` and instead offset the highlight positions in the
rendering code.
This solution requires that the fuzzy match text not change on
completion resolution. This is a property we want anyway, since fuzzy
match text changing means items unexpectedly changing position in the
menu.
What happened:
* #21521 updated completion resolution to modify labels on resolution.
- This interacted poorly with the code
[here](https://github.com/zed-industries/zed/blob/341e65e12289c355cbea6e91daee5493bbac921f/crates/editor/src/code_context_menus.rs#L604),
where the fuzzy match results are updated to include the full label, and
the fuzzy match result positions are offset to be in the correct place.
The fuzzy mach positions were now invalid because they were based on the
old text.
* #21705 caused completion resolution to occur more frequently. Before
this only the selected item was being resolved. This caused the panic
due to invalid positions to happen much more frequently.
Closes#21837
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/4925https://github.com/user-attachments/assets/e7b87375-893f-41ae-a2d9-d501499e40d1
Allows to fold any buffer inside multi buffers, either by clicking the
chevron icon on the header, or by using
`editor::Fold`/`editor::UnfoldLines`/`editor::ToggleFold`/`editor::FoldAll`
and `editor::UnfoldAll` actions inside the multi buffer (those were noop
there before).
Every fold has a fake line inside it, so it's possible to navigate into
that via the keyboard and unfold it with the corresponding editor
action.
The state is synchronized with the outline panel state: any fold inside
multi buffer folds the corresponding file entry; any file entry fold
inside the outline panel folds the corresponding buffer inside the multi
buffer, any directory fold inside the outline panel folds the
corresponding buffers inside the multi buffer for each nested file entry
in the panel.
Release Notes:
- Added a possibility to fold buffers inside multi buffers
---------
Co-authored-by: Antonio Scandurra <antonio@zed.dev>
Co-authored-by: Max Brunsfeld <max@zed.dev>
Co-authored-by: Cole Miller <cole@zed.dev>
Still TODO:
* [x] Factor out `start_language_server` so we can call it on register
(instead of on detect language)
* [x] Only call register in singleton editors (or when
editing/go-to-definition etc. in a multibuffer?)
* [x] Refcount on register so we can unregister when no buffer remain
* [ ] (maybe) Stop language servers that are no longer needed after some
time
Release Notes:
- Fixed language servers starting when doing project search
- Fixed high CPU usage when ignoring warnings in the diagnostics view
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Cole <cole@zed.dev>
Release Notes:
- Improved LSP resolution of documentation for completions. It now
queries documentation for visible completions and avoids doing too many
redundant queries.
---
In #21286, documentation resolution was made more efficient by only
resolving the current completion. However, this meant that single line
documentation shown inline in the menu was missing until scrolled
to. This also meant that it would wait for navigation to resolve
completion docs, leading to lag for displaying documentation.
This change resolves this by attempting to fetch all the completions
that will be shown. It also mostly avoids re-resolving completions. It
intentionally re-resolves the current selection on navigation, as some
language servers will respond with more information later on.
These were silently passing after the delay in updating diagnostics was
added.
Co-Authored-By: Max <max@zed.dev>
cc @someonetoignore
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
This is a no-functionality refactor of where the `ContextMenu` type is
defined. Just the type definition and implementation is up to almost
1,000 lines; so I've moved it to it's own file and renamed the type to
`CodeContextMenu`
Release Notes:
- N/A
Release Notes:
- Added `show_completions_on_input` and `show_completion_documentation`
per-language settings. These settings were available before, but were
not configurable per-language.
This is a pure refactor of our Git diff state management. Buffers are no
longer are associated with one single diff (the unstaged changes).
Instead, there is an explicit project API for retrieving a buffer's
unstaged changes, and the `Editor` view layer is responsible for
choosing what diff to associate with a buffer.
The reason for this change is that we'll soon want to add multiple "git
diff views" to Zed, one of which will show the *uncommitted* changes for
a buffer. But that view will need to co-exist with other views of the
same buffer, which may want to show the unstaged changes.
### Todo
* [x] Get git gutter and git hunks working with new structure
* [x] Update editor tests to use new APIs
* [x] Update buffer tests
* [x] Restructure remoting/collab protocol
* [x] Update assertions about staged text in
`random_project_collaboration_tests`
* [x] Move buffer tests for git diff management to a new spot, using the
new APIs
Release Notes:
- N/A
---------
Co-authored-by: Richard <richard@zed.dev>
Co-authored-by: Cole <cole@zed.dev>
Co-authored-by: Conrad <conrad@zed.dev>
Closes https://github.com/zed-industries/zed/issues/21516
Technically, this is an LSP violation from `vtsls`, but seems that it's
not going to be fixed adequately on that side, see
https://github.com/yioneko/vtsls/issues/213 for more context.
So, we have to accommodate at least for now.
Release Notes:
- Fixed completion item labels not being updated after the resolve for
non-LSP compliant servers
When searching within a single buffer, activating a search result causes
any fold containing the result to be unfolded. However, this didn't
happen when jumping to a search result from a project-wide search
multibuffer. This PR fixes that.
Release Notes:
- Fixed folds not opening when jumping from search results multibuffer
Closes https://github.com/zed-industries/zed/issues/21205
Zed does completion resolve on every menu item selection and when
applying the edit, so resolving all completion menu list is excessive
indeed.
In addition to that, removes the documentation-centric approach of menu
resolves, as we're actually resolving these for more than that, e.g.
additionalTextEdits and have to do that always, even if we do not show
the documentation.
Potentially, we can omit the second resolve too, but that seems
relatively dangerous, and many servers remove the `data` after the first
resolve, so a 2nd one is not that harmful given that we used to do much
more
Release Notes:
- Reduced the amount of `completionItem/resolve` calls done in the
completion menu
Change the "Apply" and "Discard" buttons to match @danilo-leal's design!
Here are some different states:
### Cursor in the first hunk
Now that the cursor is in a particular hunk, we show the "Apply" and
"Discard" names, and the keyboard shortcut. If I press the keyboard
shortcut, it will only apply to this hunk.
<img width="759" alt="Screenshot 2024-11-23 at 10 54 45 PM"
src="https://github.com/user-attachments/assets/68e0f109-9493-4ca2-a99c-dfcbb4d1ce0c">
### Cursor in the second hunk
Moving the cursor to a different hunk changes which buttons get the
keyboard shortcut treatment. Now the keyboard shortcut is shown next to
the hunk that will actually be affected if you press that shortcut.
<img width="749" alt="Screenshot 2024-11-23 at 10 56 27 PM"
src="https://github.com/user-attachments/assets/59c2ace3-6972-4a60-b806-f45e8c25eaae">
Release Notes:
- Restyled Apply/Discard buttons
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Bennet Bo Fenner <53836821+bennetbo@users.noreply.github.com>
Perhaps this was intentional behavior, but if not, I've attempted to
write this hacky fix — I noticed using the vertical arrow keys to move
past the document start/end would reset the goal_x to either zero (for
moving upwards) or the line width (for moving downwards). This change
makes Zed match most native text fields (at least on macOS) which leave
goal_x unchanged, even when hitting the end of the document.
I tested this change manually. Would be happy to add automatic tests for
it too, but couldn't find any existing cursor movement tests.
Release Notes:
- Behavior when moving vertically past the start or end of a document
now matches native text fields; it no longer resets the selection goal
Closes: #12739
Release Notes:
Solves #12739 by
- Enable snippet parsing to successfully parse snippets with choices
- Show completion menu when tabbing to a snippet variable with multiple
choices
Todo:
- [x] Parse snippet choices
- [x] Open completion menu when tabbing to a snippet variable with
several choices (Thank you Piotr)
- [x] Get snippet choices to reappear when tabbing back to a previous
tabstop in a snippet
- [x] add snippet unit tests
- [x] Add fuzzy search to snippet choice completion menu & update
completion menu based on choices
- [x] add completion menu unit tests
Current State:
Using these custom snippets
```json
"my snippet": {
"prefix": "log",
"body": ["type ${1|i32, u32|} = $2"],
"description": "Expand `log` to `console.log()`"
},
"my snippet2": {
"prefix": "snip",
"body": [
"type ${1|i,i8,i16,i64,i32|} ${2|test,test_again,test_final|} = $3"
],
"description": "snippet choice tester"
}
```
Using snippet choices:
https://github.com/user-attachments/assets/d29fb1a2-7632-4071-944f-daeaa243e3ac
---------
Co-authored-by: Piotr Osiewicz <piotr@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Closes#18896
Release Notes:
- Fixed#18896 - `editor::Rewrap` now preserves cursors and only inserts
whitespace by using character-level diff instead of line-level diff.
This spawns the runnable task that that's closest to the cursor.
One thing missing right now is that it doesn't find tasks that are
attached to non-outline symbols, such as subtests in Go.
Release Notes:
- Added a new reveal option for tasks: `"no_focus"`. If used, the tasks
terminal panel will be opened and shown, but not focused.
- Added a new `editor: spawn nearest task` action that spawns the task
with a run indicator icon nearest to the cursor. It can be configured to
also use a `reveal` strategy. Example:
```json
{
"context": "EmptyPane || SharedScreen || vim_mode == normal",
"bindings": {
", r t": ["editor::SpawnNearestTask", { "reveal": "no_focus" }],
}
}
```
Demo:
https://github.com/user-attachments/assets/0d1818f0-7ae4-4200-8c3e-0ed47550c298
---------
Co-authored-by: Bennet <bennet@zed.dev>
Closes#19459
This PR adds the optional setting to insert comment character(s) at the
beginning of the line(s) instead of after the indentation. It can be
enabled via keybindings:
```
"ctrl-/": ["editor::ToggleComments", { "ignore_indent": true }]
```
As suggested by @notpeter in #19459, this is implemented in
`toggle_comments` (editor.rs) taking the existing `advance_downwards`
option as example.
There's also a test case for the setting, which mimics the test case for
the regular comment toggling behavior.
---
I am not entirely happy with the name `ignore_indent`. The default would
be a double negative now `ignore_indent=false`. A positive wording would
probably easier to understand, but I could not think of anything
concise. `insert_at_line_start` or just `at_line_start` might work, but
didn't convince me either. That said, I am happy to change the name if
there are better ideas.
---
Release Notes:
- Added optional setting to insert comment character(s) at the beginning
of the line(s) instead of after the indentation. It can be used by
changing the default mapping to toggle comments like this: `"ctrl-/":
["editor::ToggleComments", { "ignore_indent": true }]`
Release Notes:
- Added a new `editor: format selections` action that allows formatting
only the currently selected text via the primary language server.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
After https://github.com/rust-lang/rust-analyzer/pull/18167 and certain
people who type and complete rapidly, it turned out that we have not
waited for `completionItem/resolve` to finish before applying the
completion results.
Release Notes:
- Fixed completion items applied improperly on fast typing
Fixes https://github.com/zed-industries/zed/issues/18405
In https://github.com/zed-industries/zed/pull/18313, we introduced a
problem where git addition highlights might spuriously return when
undoing certain changes. It turned out, there were already some cases
where git hunk highlighting was incorrect when editing at the boundaries
of expanded diff hunks.
In this PR, I've introduced a test helper method for more rigorously
(and readably) testing the editor's git state. You can assert about the
entire state of an editor's diff decorations using a formatted diff:
```rust
cx.assert_diff_hunks(
r#"
- use some::mod1;
use some::mod2;
const A: u32 = 42;
- const B: u32 = 42;
const C: u32 = 42;
fn main() {
- println!("hello");
+ //println!("hello");
println!("world");
+ //
+ //
}
fn another() {
println!("another");
+ println!("another");
}
- fn another2() {
println!("another2");
}
"#
.unindent(),
);
```
This will assert about the editor's actual row highlights, not just the
editor's internal hunk-tracking state.
I rewrote all of our editor diff tests to use these more high-level
assertions, and it caught the new bug, as well as some pre-existing bugs
in the highlighting of added content.
The problem was how we *remove* highlighted rows. Previously, it relied
on supplying exactly the same range as one that we had previously
highlighted. I've added a `remove_highlighted_rows(ranges)` APIs which
is much simpler - it clears out any row ranges that intersect the given
ranges (which is all that we need for the Git diff use case).
Release Notes:
- N/A
Closes#6822
Updates #5142
Release Notes:
- Added new fold actions to toggle folds (`cmd-k cmd-l`), fold every
fold (`cmd-k cmd-0`) unfold every fold (`cmd-k cmd-j`) to fold
recursively (`cmd-k cmd-[`) and unfold recursively (`cmd-k cmd-]`).
- vim: Added `za` to toggle fold under cursor.
- vim: Added `zO`/`zC`/`zA` to open, close and toggle folds recursively
(and fixed `zc` to not recurse into selections).
- vim: Added `zR`/`zM` to open/close all folds in the buffer.