This PR renames `language::Buffer::new` to `language::Buffer::local` and
simplifies its interface. Instead of taking a replica id (which should
always be 0 for the local case) and a `BufferId`, which was awkward and
verbose to construct, it simply takes text and a `cx`.
It uses the `cx` to derive a `BufferId` from the `EntityId` associated
with the `cx`, which should always be positive based on the following
analysis...
We convert the entity id to a u64 using this method on `EntityId`, which
is defined by macros in the `slotmap` crate:
```rust
pub fn as_ffi(self) -> u64 {
(u64::from(self.version.get()) << 32) | u64::from(self.idx)
}
```
If you look at the type of `version` in `KeyData`, it is non-zero:
```rust
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct KeyData {
idx: u32,
version: NonZeroU32,
}
```
This commit also adds `Context::reserve_model` and
`Context::insert_model` to determine a model's entity ID before it is
created, which we need in order to assign a `BufferId` in the background
when loading a buffer asynchronously.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
This PR adds the ability for extensions to provide certain language
settings via the language `config.toml`.
These settings are then merged in with the rest of the settings when the
language is loaded from the extension.
The language settings that are available are:
- `tab_size`
- `hard_tabs`
- `soft_wrap`
Additionally, for bundled languages we moved these settings out of the
`settings/default.json` and into their respective `config.toml`s .
For languages currently provided by extensions, we are leaving the
values in the `settings/default.json` temporarily until all released
versions of Zed are able to load these settings from the extension.
---
Along the way we ended up refactoring the `Settings::load` method
slightly, introducing a new `SettingsSources` struct to better convey
where the settings are being loaded from.
This makes it easier to load settings from specific locations/sets of
locations in an explicit way.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Release Notes:
- Fixed `cgn` backwards movement problem in #9982
There are two issues:
- When there are no more matches, the next repetition still moves the
cursor to the left. After that, the recording is cleared. For this I
simply move the cursor to the right, but it doesn't work when the cursor
is at the end of the line.
- If `cgn` is used when there are no matches, it cleans the previous
recorded actions. Maybe there should be a way to revert the recording.
This also happens when using `c` and `esc`
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
For #4965
There are still some minor issues:
1. When change the surround and delete the surround, we should also
decide whether there are spaces inside after deleting/replacing
according to whether it is open parentheses, and replace them
accordingly, but at present, delete and change, haven't done this
adaptation for current pr, I'm not sure if I can fit it in the back or
if it needs to be fitted together.
2. In the selection mode, pressing s plus brackets should also trigger
the Add Surrounds function, but this MR has not adapted the selection
mode for the time being, I think we need to support different add
behaviors for the three selection modes.(Currently in select mode, s is
used for Substitute)
3. For the current change surrounds, if the user does not find the
bracket that needs to be matched after entering cs, but it is a valid
bracket, and will wait for the second input before failing, the better
practice here should be to return to normal mode if the first bracket is
not found
4. I reused BracketPair in language, but two of its properties weren't
used in this mr, so I'm not sure if I should create a new struct with
only start and end, which would have less code
I'm not sure which ones need to be changed in the first issue, and which
ones can be revised in the future, and it seems that they can be solved
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Fixes: #10266
Release Notes:
- Added/Fixed/Improved ...
([#<public_issue_number_if_exists>](https://github.com/zed-industries/zed/issues/<public_issue_number_if_exists>)).
Optionally, include screenshots / media showcasing your addition that
can be included in the release notes.
**or**
- N/A
Release Notes:
- Resolves#4273
@algora-pbc /claim #4273
This is a work-in-progress. The process for `gn` command is:
- maintain updated vim.workspace_state.search.initial_query
- modify editor.select_next_state with
vim.workspace_state.search.initial_query
- use editor.select_next()
- merge selections
- set editor.select_next_state to previous state
To make this possible, several private members and editor structures are
made public. `gN` is not yet implemented and the cursor still does not
jump to the next selection in the first use.
Maybe there is an better way to do this?
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Release Notes:
- N/A
This commit introduces a new method `range` to calculate the target
range for selection expansion based on the current selection, movement
times, and other parameters. The `expand_selection` method is refactored
to use this new `range` method, simplifying the logic for expanding a
selection and making the code more modular and reusable. The `range`
method encapsulates the logic for calculating the new selection range,
including handling linewise selection and adjustments for surrounding
newlines, making it easier to understand and maintain the selection
expansion functionality.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Refs #9647
Fixes https://github.com/zed-industries/zed/issues/9792
This pull request moves the computation of scrollbar markers off the
main thread, to prevent them from grinding the editor to a halt when we
have a lot of them (e.g., when there are lots of search results on a
large file). With these changes we also avoid generating multiple quads
for adjacent markers, thus fixing an issue where we stop drawing other
primitives because we've drawn too many quads in the scrollbar.
Release Notes:
- Improved editor performance when displaying lots of search results,
diagnostics, or symbol highlights in the scrollbar
([#9792](https://github.com/zed-industries/zed/issues/9792)).
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Nathan <nathan@zed.dev>
Release Notes:
- Fixes#4502
Notes:
I removed this line of code which removes the vim keymap contexts when
an editor is blurred.
16e6f5643c/crates/vim/src/vim.rs (L703-L705)
I tried whether the editor context would be poisoned when switching
between two editors and disabling vim mode and switching back but the
context looked normal. If this change is wrong, please advise. I could
not find why this piece of code was required.
This fixes#4502 as the reason why keybinds did not show up was because
the vim context was removed from the editor's keymap contexts. Other
paths for a fix could be to filter out vim predicates when finding
keybinds for actions but I believe that'd add unnecessary complexity.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Fix#8994 and #9844
Release notes:
* Fixed the `t` object in Vim mode not working correctly when cursor was
on a tag. #9844 and #8994
This mr fixes the above two problems, for #9844, because our previous
logic is to only think that the minimum html tag containing the current
cursor is qualified, but the approach of nvim is to get the tag after
the current cursor first, followed by the tag around the current cursor,
so I modified the corresponding condition
For #8994, the situation is a bit more complicated, in our previous
implementation, we could only get the range of the object by a `cursor
position`, but there are two possible cases for the html tag:
When the current cursor length is 1, nvim will return the first tag
after the current cursor, as described above
When the current cursor length is greater than 1, nvim will return just
the smallest tag that can cover the current selection
So we may need to pass the current selection to the inside of the
method, and the point alone is not enough to support us in calculating
these conditions
This pull request introduces a new `InlineCompletionProvider` trait,
which enables making `Editor` copilot-agnostic and lets us push all the
copilot functionality into the `copilot_ui` module. Long-term, I would
like to merge `copilot` and `copilot_ui`, but right now `project`
depends on `copilot`, which makes this impossible.
The reason for adding this new trait is so that we can experiment with
other inline completion providers and swap them at runtime using config
settings.
Please, note also that we renamed some of the existing copilot actions
to be more agnostic (see release notes below). We still kept the old
actions bound for backwards-compatibility, but we should probably remove
them at some later version.
Also, as a drive-by, we added new methods to the `Global` trait that let
you read or mutate a global directly, e.g.:
```rs
MyGlobal::update(cx, |global, cx| {
});
```
Release Notes:
- Renamed the `copilot::Suggest` action to
`editor::ShowInlineCompletion`
- Renamed the `copilot::NextSuggestion` action to
`editor::NextInlineCompletion`
- Renamed the `copilot::PreviousSuggestion` action to
`editor::PreviousInlineCompletion`
- Renamed the `editor::AcceptPartialCopilotSuggestion` action to
`editor::AcceptPartialInlineCompletion`
---------
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Kyle <kylek@zed.dev>
Co-authored-by: Kyle Kelley <rgbkrk@gmail.com>
I found that there may be some minor problems here, in editor.edit may
be more dependent on the order of operations, if the same set of
operations, different execution orders may lead to some different
results, so maybe we need to use BTreeSet instead of HashSet, because
HashSet may not be able to ensure that the same set of data order is
consistent, but maybe my worries are too much
Release notes:
- N/A
This PR refactors the `CommandPaletteFilter` and
`CommandPaletteInterceptor` to better encapsulate their internals.
Previously these globals and their fields were publicly accessible,
which meant that there was a lot of reaching in and making
modifications.
These changes should make it easier to add additional consumers of these
hooks (right now they're primarily used by Vim mode).
Release Notes:
- N/A
In this commit, the Copy trait has been removed from Operator. This
change was necessary due to the value of operator may wish to attach a
motion type, which is not compatible with the Copy trait.
All instances where Operator was previously copied have been updated to
use the clone() or cloned() method instead. This includes function
parameters, variable assignments, and closures.
For #4440, I've only added support for normal, if it's visual mode,
would we like this to delete the current selection row and enter insert
mode?
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
The important change here is to ensure that undo never lands you in
visual mode; but we also take care to restore the selection the same way
vim does (visual line goes to beginning of line, visual block to the top
left, etc.).
To help make this behaviour feel right we also group any deletions that
started insert mode with the first text inserted.
Fixes: #7521
Release Notes:
- vim: Improved undo. It will now restore you to normal mode in the same
position as vim, and group deletions caused by `c` or `s` with the
concomitant insert.
([#7521](https://github.com/zed-industries/zed/issues/7521)).
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
This PR adds support for `ap`/`ip` text objects in Vim mode and allows
users to perform paragraph-based operations.
Cases where compatibility with Neovim's behavior is checked, cases where
there are known differences in behavior with Neovim (cases where the
landing position is other than the beginning of the line), and cases
where the Neovim behavior in the test suite seems strange are separated
in the test code so that they can be identified.
Release Notes:
- Added support for `ap` and `ip` paragraph text objects in Vim mode
([#7359](https://github.com/zed-industries/zed/issues/7359)).
This PR adds **internal** ability to run arbitrary language servers via
WebAssembly extensions. The functionality isn't exposed yet - we're just
landing this in this early state because there have been a lot of
changes to the `LspAdapter` trait, and other language server logic.
## Next steps
* Currently, wasm extensions can only define how to *install* and run a
language server, they can't yet implement the other LSP adapter methods,
such as formatting completion labels and workspace symbols.
* We don't have an automatic way to install or develop these types of
extensions
* We don't have a way to package these types of extensions in our
extensions repo, to make them available via our extensions API.
* The Rust extension API crate, `zed-extension-api` has not yet been
published to crates.io, because we still consider the API a work in
progress.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nathan <nathan@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
I'm not sure how compliant you're aiming to be with vim, but the `f`
behavior is more useful when it can search on multiple lines instead of
a single one, so I'd like to propose this change.
This change is quite frequent in vim/neovim as a plugin (e.g.
[clever-f](https://github.com/VSCodeVim/Vim),
[improved-ft](https://github.com/backdround/improved-ft.nvim), etc), and
in other vim emulations (e.g.
[vscode-vim](https://github.com/VSCodeVim/Vim)).
a simple code for html tag support, I've only done the basics, and if
it's okay, I'll optimize and organize the code, and adapt other parts
like `is_multiline`, `always_expands_both_ways`, `target_visual_mode`,
etc
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Release Notes:
- Added
[`:tabo[nly][!]`](https://neovim.io/doc/user/tabpage.html#%3Atabonly),
closes all the tabs except the active one but in the current pane only,
every other split pane remains unaffected.
The version with the `!` force closes the tabs while the one without
asks you to save or discard the changes.
- Added [`:on[ly][!]`](https://neovim.io/doc/user/windows.html#%3Aonly),
closes all the tabs *and* panes except the active one.
The version with the `!` force closes the tabs while the one without
asks you to save or discard the changes.
Since Zed does not have different splits per tab like in Neovim `:only`
works the same as it does in VscodeVim.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR introduces a new `command_palette_hooks` crate that contains the
types used to hook into the behavior of the command palette.
The `CommandPaletteFilter` was previously extracted to the `copilot`
crate in #7095, solely because that was the earliest ancestor of the
crates that depended on it.
The `CommandPaletteInterceptor` was still defined in `command_palette`
itself.
Both of these types were consumed by other crates wanting to influence
the behavior of the command palette, but required taking a dependency on
the entire `command_palette` crate in order to gain access to these
hooks.
By moving them out into their own crate, we can improve the compile
order and make crates like `vim` able to begin building sooner without
having to wait for `command_palette` to finish compiling.
Here's a comparison of the compilation graph before and after (ignore
the timings):
#### Before
<img width="332" alt="Screenshot 2024-02-25 at 12 42 29 PM"
src="https://github.com/zed-industries/zed/assets/1486634/a57c662e-fbc2-41ab-9e30-cca17afa6c73">
#### After
<img width="362" alt="Screenshot 2024-02-25 at 12 51 15 PM"
src="https://github.com/zed-industries/zed/assets/1486634/c1a6d29c-b607-4604-8f1b-e5d318bf8849">
Release Notes:
- N/A
This PR adds a new `argument` vim text object, inspired by
[targets.vim](https://github.com/wellle/targets.vim).
As it's the first vim text object to use the syntax tree, it needed to
operate on the `Buffer` level, not the `MultiBuffer` level, then map the
buffer coordinates to `DisplayPoint` as necessary.
This required two main changes:
1. `innermost_enclosing_bracket_ranges` and `enclosing_bracket_ranges`
were moved into `Buffer`. The `MultiBuffer` implementations were updated
to map to/from these.
2. `MultiBuffer::excerpt_containing` was made public, returning a new
`MultiBufferExcerpt` type that contains a reference to the excerpt and
methods for mapping to/from `Buffer` and `MultiBuffer` offsets and
ranges.
Release Notes:
- Added new `argument` vim text object, inspired by
[targets.vim](https://github.com/wellle/targets.vim).
Release Notes:
- vim: Added a setting to control default clipboard behaviour. `{"vim":
{"use_system_clipboard": "never"}}` disables writing to the clipboard.
`"on_yank"` writes to the system clipboard only on yank, and `"always"`
preserves the current behavior. ([#4390
](https://github.com/zed-industries/zed/issues/4390))
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Release Notes:
- Added `workspace::SendKeystrokes` to enable mapping from one key to a
sequence of others
([#7033](https://github.com/zed-industries/zed/issues/7033)).
Improves #7033. Big thank you to @ConradIrwin who did most of the heavy
lifting on this one.
This PR allows the user to send multiple keystrokes via custom
keybinding. For example, the following keybinding would go down four
lines and then right four characters.
```json
[
{
"context": "Editor && VimControl && !VimWaiting && !menu",
"bindings": {
"g z": [
"workspace::SendKeystrokes",
"j j j j l l l l"
],
}
}
]
```
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Undoubtedly not perfect, but this should be something we can work off
of.
Note that matching keybindings with ctrl in them is currently broken on
linux (or at least x11). This keymap might just manage to be less useful
than using the macos one on linux until that is fixed... the proximate
cause of this is that the `key` field of the `Keystroke` struct looks
like `"\u{e}"` instead of `"n"` when `ctrl-n` is pressed.
Release Notes:
- N/A
Activated by keystrokes g-e.
Release Notes:
- vim: Added `ge` and `gE` for go to Previous Word End.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Fixes: #7605
When repeating some cursor movements in Vim mode (e.g. `99999999 w`),
Zed tries to repeat the movement that many times, even if further
actions don't have any effect. This causes Zed to hang.
This commit makes those movements like other actions (like moving the
cursor left/right), stopping the repeat movement if a boundary of the
text is reached/the cursor can't move anymore.
Release Notes:
- Fixed [#7605](https://github.com/zed-industries/zed/issues/7605).
Fixes: #7311
Co-Authored-By: WindSoilder <WindSoilder@outlook.com>
Release Notes:
- Added a highlight on yanked text in vim normal mode
**or**
- N/A
Co-authored-by: WindSoilder <WindSoilder@outlook.com>
This was originally just to fix
https://github.com/zed-industries/zed/issues/4354, which I did by just
returning the previous offset in `find_boundary`.. but `find_boundary`
is used in the "insert mode" / normal editor too, so returning the
previous boundary breaks existing functionality in that case.
I was considering a new `find_boundary` function just for some of the
vim motions like this, but I thought that this is straightforward enough
and future Vim functions might need similar logic too.
Release Notes:
- Fixed https://github.com/zed-industries/zed/issues/4354
- Add a setting for `vertical_scroll_offset`
- Fix H/M/L in vim with scrolloff
Release Notes:
- Added a settings for `vertical_scroll_offset`
- vim: Fix H/M/L with various values of vertical_scroll_offset
---------
Co-authored-by: Vbhavsar <vbhavsar@gmail.com>
Co-authored-by: fdionisi <code@fdionisi.me>
Based on the great work in
https://github.com/zed-industries/zed/pull/7130 , now sends this data
```
[crates/lsp/src/lsp.rs:588] ClientInfo { name: name.to_string(), version: Some(version.to_string()) } = ClientInfo {
name: "Zed Dev",
version: Some(
"0.122.0",
),
}
```
with every LSP server initialization.
Release Notes:
- Added Zed name and version to LSP InitializeParams requests
This PR fixes some formatting issues in some of the `Cargo.toml` files.
I tried to fix most of these in #7126, but there were a few that I
missed.
Release Notes:
- N/A
This PR sorts the dependency lists in our `Cargo.toml` files so that
they are in alphabetical order.
This should make them easier to visually scan when looking for a
dependency.
Apologies in advance for any merge conflicts 🙈
Release Notes:
- N/A
This should prevent a class of bugs where one queries the wrong type of
global, which results in oddities at runtime.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This fixes#6815 by implementing `<space>` in normal mode in Vim. Turns
out that `<space>` behaves like a reverse `<backspace>` (which we
already had): it goes to the right and, if at end of line, to the next
line.
That means I had to touch `movement::right`, which is used in a few
places, but it's documentation said that it would go to the next line,
which it did *not*. So I changed the behaviour.
But I would love another pair of eyes on this, because I don't want to
break non-Vim behaviour.
Release Notes:
- Added support for `<space>` in Vim normal mode: `<space>` goes to the
right and to next line if at end of line.
([#6815](https://github.com/zed-industries/zed/issues/6815)).
This fixes `t` not being repeatable with `,` and `;` in normal mode.
Release Notes:
- Fixed `t` in Vim mode not being repeatable with `,` or `;`.
---------
Co-authored-by: Conrad <conrad@zed.dev>
This change implements the vim
[motion](https://github.com/vim/vim/blob/master/runtime/doc/motion.txt)
commands to move the cursor to the top, middle and bottom of the visible
view. This feature is requested in
https://github.com/zed-industries/zed/issues/4941.
This change takes inspiration from
[crates/vim/src/normal/scroll.rs](https://github.com/zed-industries/zed/blob/main/crates/vim/src/normal/scroll.rs).
A note on the behavior of these commands: Because
`NeovimBackedTestContext` requires compatibility with nvim, the current
implementation causes slightly non-standard behavior: it causes the
editor to scroll a few lines. The standard behavior causes no scrolling.
It is easy enough to account for the margin by adding
`VERTICAL_SCROLL_MARGIN`. However, doing so will cause test failures due
to the disparity between nvim and zed states. Perhaps
`NeovimBackedTestContext` should have a switch to be more tolerant for
such cases.
Release Notes:
- Added support for moving to top, middle and bottom of the screen in
vim mode (`H`, `M`, and `L`)
([#4941](https://github.com/zed-industries/zed/issues/4941)).
Closes#4358
The bug originates on this line:
5db7e8f89e/crates/vim/src/motion.rs (L451)
- When running "dtx" on "ˇabcx", the range to delete is 0 -> 2 ("abc")
- When running "dtx" on "abˇcx", the range to delete is 2 -> 2 ("c"), so
`new_point == point` and the function incorrectly returns `None` and "c"
is not deleted
- We need to disambiguate between the "not found" case and the "found
immediately to the right" case
- This bug does not apply to the backwards case ("dTx")
Release Notes:
- Fixed "dtx" vim key combination when "x" is immediately to the right
of the cursor (#4358)
- [x] Fill in GPL license text.
- [x] live_kit_client depends on live_kit_server as non-dev dependency,
even though it seems to only be used for tests. Is that an issue?
Release Notes:
- N/A
This matches Neovim behaviour by setting the mode to `Normal` when using
search while in visual mode.
Release Notes:
- Fixed Vim mode not switching to normal mode from visual mode when
using search (`/`) while in visual mode.
Fixes */# in visual mode, and avoids setting up irritating state.
[[PR Description]]
Release Notes:
- vim: Improved `*` and `#` to not toggle Zed's search state. Instead we
now use the regex to identify start and end of words (more like vim).
This PR updates the tenses used by the summary line of doc comments to
match the [Rust API documentation
conventions](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#summary-sentence).
Specifically:
> The summary line should be written in third person singular present
indicative form. Basically, this means write ‘Returns’ instead of
‘Return’.
I'm sure there are plenty occurrences that I missed.
Release Notes:
- N/A
Adding the typos crate to our CI will take some doing, as we have
several tests which rely on typos in various ways (e.g. checking state
as the user types), but I thought I'd take a first stab at fixing what
it finds.
Release Notes:
- N/A
