Related to #21481 ; it fixes a bunch of hotspots I saw while looking at
the provided profiles. MultiBuffer still takes up 100% CPU on the
foreground thread for me - this time around it's on selection updates
(when dragging the selected text towards an edge of a screen).
Release Notes:
- N/A
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.
Some of our users ran into a peculiar bug: autoimports with vtsls were
leaving behind an extra curly brace. I think we were slightly incorrect
in always requesting a follow-up completion without regard for last
result of completion request (whether it was incomplete or not).
Specifically, we're falling into this branch in current form:
037c2b615b/packages/service/src/service/completion.ts (L121)
which then leads to incorrect edits being returned from vtsls.
Release Notes:
- Fixed an edge case with appliance of autocompletions in VTSLS that
could result in incorrect edits being applied.
The goal of #7115 appears to be to limit the disruptiveness of
completion documentation load causing the completion selector to move
around. The approach was to debounce load of documentation via a setting
`completion_documentation_secondary_query_debounce`. This particularly
had a nonideal interaction with #21286, where now this debounce interval
was used between the documentation fetches of every individual
completion item.
I think a better solution is to continue making space for documentation
to be shown as soon as any documentation is shown. #21704 implemented
part of this, but it did not persist across followup completions.
Release Notes:
- Fixed completion list moving around on load of documentation. The
previous approach to mitigating this was to rate-limit the fetch of
docs, configured by a
`completion_documentation_secondary_query_debounce` setting, which is
now deprecated.
In #21286, documentation fetch was made more efficient by only
fetching the current completion. This has a side effect of causing the
aside to disappear and reappear when navigating the list. This is
particularly jarring when there isn't enough space for the aside,
causing the completions list to jump to the left.
The solution here is to continue to show the aside even if the current
selection does not yet have docs fetched.
Release Notes:
- N/A
I ran into a case locally where the project diff view was unexpectedly
empty because the first file to be scanned wasn't valid UTF-8, and the
inmost loop in `schedule_worktree_rescan` currently breaks when any
loading task fails. It seems like it might make more sense to continue
with the rest of the buffers in this case and also when
`Project::open_unstaged_changes` fails. I've left the error handling for
`update` as-is.
Release Notes:
- Fix project diff view missing files
This fixes an error on nightly, introduced in
https://github.com/zed-industries/zed/pull/21258, where diffs were not
shown for buffers that were added to multi-buffers after construction.
Release Notes:
- N/A
During workspace registration, it's too early to check for the
`is_staff` flag due to no connection being established yet.
As a compromise, allow the action to appear and be registered, but do
nothing for non-staff users.
Release Notes:
- N/A
Closes#21576
This issue is caused by the fuzzy matching for snippets I added
[here](https://github.com/zed-industries/zed/pull/21524). When
encountering symbols such as `:`, `(`, `.`, etc., the `last_word`
becomes empty, which results in an empty string being passed to
`fuzzy_match`, leading to the return of all templates.
This fix adds an early return when `last_word` is empty.
Release Notes:
- N/A
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
Part of https://github.com/zed-industries/zed/issues/20925
This prototype is behind a feature flag and being merged to avoid
conflicts with further git-related resturctures.
To be a proper, public feature, this needs at least:
* showing deleted files
* better performance
* randomized tests
* `TODO`s in the `project_diff.rs` file fixed
The good thing is, >90% of the changes are in the `project_diff.rs` file
only, have a basic test and already work on simple cases.
Release Notes:
- N/A
---------
Co-authored-by: Thorsten Ball <thorsten@zed.dev>
Co-authored-by: Cole Miller <cole@zed.dev>
This addresses the editor context menu portion of #17819.
Release Notes:
- Added `editor::OpenContextMenu` action to open context menu at current
cursor position.
Closes#19054
Rename `max_buffer_row()` to `widest_line_number()` to (hopefully)
prevent
people assuming it means the same as `max_point().row`.
Release Notes:
- Fixed a panic when folding in a multibuffer
Closes#4642
- Added the ability to switch to helix normal mode, with an additional
helix visual mode.
- <kbd>ctrl</kbd><kbd>h</kbd> from Insert mode goes to Helix Normal
mode. <kbd> i </kbd> and <kbd> a </kbd> to go back.
- Need to find a way to perform the helix normal mode selection with
<kbd> w </kbd>, <kbd>e </kbd>, <kbd> b </kbd> as a first step. Need to
figure out how the mode will interoperate with the VIM mode as the new
additions are in the same crate.
Related to #19424
This uses the new text object support, so will only work for languages
that have `textobjects.scm`. It does not integrate with
indentation-based folding for now, and the syntax-based folds don't have
matching fold markers in the gutter (unless they are folded).
Release Notes:
- Add an editor action to fold all function bodies
Co-authored-by: Conrad <conrad@zed.dev>
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/12029
Allows to introspect project items inside items more deeply, checking
them for being dirty.
For that:
* renames `project::Item` into `project::ProjectItem`
* adds an `is_dirty(&self) -> bool` method to the renamed trait
* changes the closing logic to only care about dirty project items when
checking for save prompts conditions
* save prompts are raised only if the item is singleton without a
project path; or if the item has dirty project items that are not open
elsewhere
Release Notes:
- Fixed item closing overly triggering save dialogues
Closes https://github.com/zed-industries/zed/issues/10196
I think having this action exposed in the editor controls menu, close to
the inline Git Blame option, makes more sense than a more prominent item
somewhere else in the app. Maybe having it there will increase its
discoverability. I myself didn't know this until a few weeks ago! Next
steps would be ensuring the menu exposes its keybindings.
(Quick note about the menu item name: I think maybe "_Git Blame Column_"
would make more sense and feel grammatically more correct, but then we
would have two Git Blame-related options, one with "Git Blame" at the
start (Inline...) and another with "Git Blame" at the end (... Column).
I guess one had to be sacrificed for the sake of consistency 😅.)
<img width="750" alt="Screenshot 2024-11-29 at 12 01 33"
src="https://github.com/user-attachments/assets/2f3324ec-a2f0-4303-9582-714d0ee6bd31">
Release Notes:
- N/A
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
I use `cmd_or_ctrl` for `multi_cursor_modifier`, but noticed that if I
hovered a code reference while holding alt, it wouldn't show the
underline. Instead, it would only show when pressing cmd. Looking at the
code, it seems like this was just a small oversight on always checking
for `modifiers.secondary`, instead of reading from the
`multi_cursor_modifier` setting to determine which button was invoking
link handling.
---
Release Notes:
- Fixed underline when hovering a code link not showing when
`multi_cursor_modifier` is `cmd_or_ctrl`
Closes https://github.com/zed-industries/zed/issues/4351
Applies the same splitting mechanism, as Zed's central pane has, to the
terminal panel.
Similar navigation, splitting and (de)serialization capabilities are
supported.
Notable caveats:
* zooming keeps the terminal splits' ratio, rather expanding the
terminal pane
* on macOs, central panel is split with `cmd-k up/down/etc.` but `cmd-k`
is a "standard" terminal clearing keybinding on macOS, so terminal panel
splitting is done via `ctrl-k up/down/etc.`
* task terminals are "split" into regular terminals, and also not
persisted (same as currently in the terminal)
Seems ok for the initial version, we can revisit and polish things
later.
Release Notes:
- Added the ability to split the terminal panel
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>
This reverts #20824 and #20899. After adding them last week we came to
the conclusion that the hints are too distracting in everyday use, see
#21128 for more details.
Release Notes:
- N/A
I've observed that Zed's implementation of [Code Actions On
Format](https://zed.dev/docs/configuring-zed#code-actions-on-format)
uses the
[CodeActionContext.only](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeActionContext)
parameter to request specific code action kinds from the server. The
issue is that it does not filter out code actions from the response,
believing that the server will do it.
The [LSP
specification](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#codeActionContext)
says that the client is responsible for filtering out unwanted code
actions:
```js
/**
* Requested kind of actions to return.
*
* Actions not of this kind are filtered out by the client before being
* shown. So servers can omit computing them.
*/
only?: CodeActionKind[];
```
This PR will filter out unwanted code action on the client side.
I have initially encountered this issue because the [ZLS language
server](https://github.com/zigtools/zls) (until
https://github.com/zigtools/zls/pull/2087) does not filter code action
based on `CodeActionContext.only` so Zed runs all received code actions
even if they are explicitly disabled in the `code_actions_on_format`
setting.
Release Notes:
- Fix the `code_actions_on_format` setting when used with a language
server like ZLS
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
See ["mtime comparison considered
harmful"](https://apenwarr.ca/log/20181113) for details of why
comparators other than equality/inequality should not be used with
mtime.
Release Notes:
- N/A
