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 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 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)
