Closes#41125
Release Notes:
- Fixed `SwitchToHelixNormalMode` to keep selection
- Added default keybinds for `SwitchToHelixNormalMode` when in Helix
mode
- Added "ctrl-p" for selecting the previous menu item
- Added "ctrl-n" for selecting the next menu item
Closes#40619
Release Notes:
- Ctrl+P now moves to the previous result; Ctrl+N moves to the next.
`vim::Substitute` is a little different from the helix behavior, so this
PR adds helix versions. The most important difference (for my usage, at
least) is that if you're selecting whole lines then helix drops the `\n`
from the selection (much like vim's lines mode, except that helix bases
this behavior on the selection instead of having a different mode).
Release Notes:
- N/A
Closes#33637Closes#37332
and solves part of
https://github.com/zed-industries/zed/discussions/33580#discussioncomment-14195506
This improves the "C" and "alt-C" actions to work like helix.
It also adds "," which removes all but the newest cursors. In helix the
one that's left would be the primary selection, but I don't think that
has an equivalent yet, so this simulates what would be the primary
selection if it was never cycled with "(" ")".
Release Notes:
- Improved multicursor creation and deletion in helix mode
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
- Add `skip_soft_wrap` field to both `AddSelectionAbove` and
`AddSelectionBelow` actions. When set to `true`, which is now
the default this will skip soft wrapped lines when extending the
selections.
- Move the `start_of_relative_buffer_row` function from the
`vim::motion` module to the `editor::display_map::DisplaySnapshot`
implementation as a method.
- Update the default behavior for both `editor: add selection above` and
`editor: add selection below` commands in order to skip over soft
wrapped lines by default, mirroring VS Code's default behavior.
- Update existing keymaps to specify this `skip_soft_wrap` value for
both `AddSelectionAbove` and `AddSelectionBelow` actions.
Closes#16979
Release Notes:
- Updated both the `editor: add selection above` and `editor: add
selection below` commands to ignore soft wrapped lines. If you wish to
restore the old behavior, add the following to your keymap file:
```
{
"context": "Editor",
"bindings": {
"cmd-alt-up": ["editor::AddSelectionAbove", { "skip_soft_wrap": false
}],
"cmd-alt-down": ["editor::AddSelectionBelow", { "skip_soft_wrap": false
}]
}
}
```
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
### What does this PR do?
- Adds default keybindings `gt` for navigating to the next tab and `gT`
for navigating to the previous tab in markdown viewer mode
### Why do we need this change?
- While previewing markdown files, the default vim bindings (`gt` and
`gT`) do not work for navigating between tabs. These bindings work
everywhere else, which provides a non-consistent experience for the
user.
### How do we do this change?
- Update the vim mode bindings to explicitly add handling for this mode
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
These changes refactor the whitespace handling logic for Vim's change
surrounds command (`cs`), making its behavior closely match
[tpope/vim-surround](https://github.com/tpope/vim-surround), following
[this
discussion](https://github.com/zed-industries/zed/issues/38169#issuecomment-3304129461).
Zed's current implementation has two main differences when compared to
[tpope/vim-surround](https://github.com/tpope/vim-surround):
- It only considers whether a single space should be added or removed,
instead of all the space that is between the surrounding character and
the content
- It only takes into consideration the new surrounding characters in
order to determine whether to add or remove that space
A review of
[tpope/vim-surround](https://github.com/tpope/vim-surround)'s behavior
reveals these rules for whitespace:
* Quote to Quote
* Whitespace is never changed
* Quote to Bracket
* If opening bracket, add one space
* If closing bracket, do not add space
* Bracket to Bracket
* If opening to opening, keep only one space
* If opening to closing, remove all space
* If closing to opening, add one space
* If closing to closing, do not change space
* Bracket to Quote
* If opening, remove all space
* If closing, preserve all space
Below is a table with examples for each scenario. A new test has also
been added to specifically check the scenarios outlined above,
`vim::surrounds::test::test_change_surrounds_vim`.
| Type | Before | Command | After |
|-------------------|-------------|---------|---------------|
| Quote → Quote | `' a '` | `cs'"` | `" a "` |
| Quote → Quote | `" a "` | `cs"'` | `' a '` |
| Quote → Bracket | `' a '` | `cs'{` | `{ a }` |
| Quote → Bracket | `' a '` | `cs'}` | `{ a }` |
| Bracket → Bracket | `[ a ]` | `cs[{` | `{ a }` |
| Bracket → Bracket | `[ a ]` | `cs[}` | `{a}` |
| Bracket → Bracket | `[ a ]` | `cs]{` | `{ a }` |
| Bracket → Bracket | `[ a ]` | `cs]}` | `{ a }` |
| Bracket → Quote | `[ a ]` | `cs['` | `'a'` |
| Bracket → Quote | `[ a ]` | `cs]'` | `' a '` |
These changes diverge from
[tpope/vim-surround](https://github.com/tpope/vim-surround) when
handling newlines. For example, with the following snippet:
```rust
fn test_surround() {
if 2 > 1 {
println!("place cursor here");
}
};
```
Placing the cursor inside the string and running any combination of
`cs{[`, `cs{]`, `cs}[`, or `cs}]` would previously remove newline
characters. With these changes, using commands like `cs}]` will now
preserve newlines.
Related to #38169Closes#39334
Release Notes:
- Improved Vim’s change surround command to closely match
[tpope/vim-surround](https://github.com/tpope/vim-surround) behavior.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Closes#10930Closes#11353
Release Notes:
- Adds commands to project_panel
- `ctrl-u` scrolls the project_panel up half of the visible entries
- `ctrl-d` scrolls the project_panel down half of the visible entries
- `z z` scrolls current selection to center of window
- `z t` scrolls current selection to top of window
- `z b` scrolls current selection to bottom of window
- `{num} j` and `{num} k` now move up and down with a count
Since 2021 Neovim remaps Y to $y (1). DO the same in zed through a new action `YankToEndOfLine`.
1: https://github.com/neovim/neovim/pull/13268
Release Notes:
- Added vim::YankToEndOfLine action which copies from the cursor to the end of the line excluding the newline. We bind it to Y by default in the vim keymap.
Vim mode currently supports `gt` (go to next tab) and `gT` (go to
previous tab) but not with count. Implement the expected behavior as
defined by vim:
- `<count>gt` moves to tab `<count>`
- `<count>gT` moves to previous tab `<count>` times (with wraparound)
Release Notes:
- Improved vim `gt` and `gT` to support count, e.g. `5gt` - go to tab 5,
`8gT` - go to 8th previous tab with wraparound.
This is a redo of #29776. I went for a separate function -- instead of
adding a bunch of conditions to `vim::Paste` -- because there were quite
a few differences.
Release Notes:
- Added a `vim::HelixPaste` command that imitates Helix's paste behavior
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Closes#34192
Without selection, only current character would be affected.
Also if #38117 is merged too, then transformations in SelectMode behave
correctly too and selection is not collapsed.
Release Notes:
- helix: Implemented `~`, `` ` ``, `` Alt-` `` correctly in normal and
select modes
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Please credit @eliaperantoni, for the original PR (#34136).
Merge after (#34060) to avoid conflicts.
Closes https://github.com/zed-industries/zed/issues/33838
Closes https://github.com/zed-industries/zed/issues/33906
Release Notes:
- Helix will no longer sometimes fall out into "normal" mode, will
remain in "helix normal" (example: vv)
- Added dedicated "helix select" mode that can be targeted by
keybindings
Known issues:
- [ ] Helix motion, especially surround-add will not properly work in
visual mode, as it won't call `helix_move_cursor`. It is possible
however to respect self.mode in change_selection now.
- [ ] Some operations, such as `Ctrl+A` (increment) or `>` (indent) will
collapse selection also. I haven't found a way to avoid it.
---------
Co-authored-by: fantacell <ghub@giggo.de>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This is an implementation of matching like "m i (", as well as "] (" and
"[ (" in `helix_mode` with a few supported objects and a basis for more.
Release Notes:
- Added helix operators for selecting text objects
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Closes https://github.com/zed-industries/zed/issues/37144
Adjusts `editor::DeleteToPreviousWordStart`,
`editor::DeleteToNextWordEnd`, `editor::DeleteToNextSubwordEnd` and
`editor::DeleteToPreviousSubwordStart` actions to
* take whitespace sequences with length >= 2 into account and stop after
removing them (whilst movement would also include the word after such
sequences)
* take current language's brackets into account and stop after removing
the text before them
The latter is configurable and can be disabled with `"ignore_brackets":
true` parameter in the action.
Release Notes:
- Improved word deletions to consider whitespace sequences and brackets
by default
Add support for scrolling the contents rendered aside an
`editor::code_context_menus::CodeContextMenu` by introducing the
`scroll_aside` method.
For now this method is only implemented for the
`CodeContextMenu::Completions` variant, which will scroll the aside
contents for an `editor::code_context_menus::CompletionsMenu` element,
as a `ScrollHandle` is added to the aside content that is rendered.
In order to be possible to trigger this via keybindings, a new editor
action is introduced, `ContextMenuScrollAside`, which accepts a number
of lines or pages to scroll the content by.
Lastly, the default keymaps for both MacOS and Linux, as well as for
Zed's vim mode, are updated to ensure that the following keybindings are
supported when a completion menu is open and the completion item's
documentation is rendered aside:
- `ctrl-e`
- `ctrl-y`
- `ctrl-d`
- `ctrl-u`
### Recording
https://github.com/user-attachments/assets/02043763-87ea-46f5-9768-00e907127b69
---
Closes#13194
Release Notes:
- Added support for scrolling the documentation panel shown alongside
the completion menu in the editor with `cltr-d`, `ctrl-u`, `ctrl-e` and
`ctrl-y`
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: MrSubidubi <finn@zed.dev>
Closes#32020
Release Notes:
- Helix: Improve `x` behaviour. Will respect modifiers (`5 x`). Pressing
`x` on a empty line, will select current+next line, because helix
considers current line to be already selected without the need of
pressing `x`.
Related #4642
Compatible with #34136
Release Notes:
- Helix: `Shift+R` works as Paste instead of taking you to ReplaceMode
- Helix: `g .` goes to last modification place (similar to `. in vim)
Closes#34763
Release Notes:
- Improved insert in `helix_mode` when a selection exists to better
match helix's behavior: collapse selection to avoid replacing it
- Improved append (`insert_after`) to better match helix's behavior:
move cursor to end of selection if it exists
Make the git blame popover available via the keymap by making it an
action. The blame popover stays open after being shown via the action,
similar to the `editor::Hover` action.
I added a default vim-mode key binding for `g b`, which goes in hand
with `g h` for hover. I'm not sure what the keybind would be for regular
layouts, if any would be set by default.
I'm opening this as a draft because I coludn't figure out a way to
position the popover correctly above/under the cursor head. I saw some
uses of `content_origin` in other places for calculating absolute pixel
positions, but I'm not sure how to make use of it here without doing a
big refactor of the blame popover code 🤔. I would appreciate some
help/tips with positioning, because it seems like the last thing to
implement here.
Opening as a draft for now because I think without the correct
positioning this feature is not complete.
Closes https://github.com/zed-industries/zed/discussions/26447
Release Notes:
- Added `editor::BlameHover` action for showing the git blame popover
under the cursor. By default bound to `ctrl-k ctrl-b` and to `g h` in
vim mode.
Closes: https://github.com/zed-industries/zed/issues/34780
Also relocated undo/redo selection in the keymap (no-op) as they are
from Sublime, not VSCode.
Release Notes:
- vim: Fixed an issue so `ctrl-w` / `ctrl-h` and `ctrl-u` work in
pickers on Linux when Vim mode is enabled.
Now ! means "no ancestors matches this", and > means "any descendent"
not "any child".
Updates #34570
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- *Breaking change*. The context predicates in the keymap file now
handle ! and > differently. Before this change ! meant "this node does
not match", now it means "none of these nodes match". Before this change
> meant "child of", now it means "descendent of". We do not expect these
changes to break many keymaps, but they may cause subtle changes for
complex context queries.
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#34111
In Helix mode, the `;` key should collapse the current selection without
moving the cursor. I've added a new action `vim::HelixCollapseSelection`
to support this behavior.
https://github.com/user-attachments/assets/1a40821a-f56f-456e-9d37-532500bef17b
Release Notes:
- Added `;` key binding to collapse the current text selection in Helix
mode
Closes#14760
Still TODO:
* Vim actually undoes *many* changes if they're all on the same line.
Release Notes:
- vim: Add `U` to return to the last changed line and undo
This Pull Request introduces various changes to the editor's horizontal
scrolling, mostly focused on vim mode's horizontal scroll motions (`z
l`, `z h`, `z shift-l`, `z shift-h`). In order to make it easier to
review, the logical changes have been split into different sections.
## Cursor Position Update
Changes introduced on https://github.com/zed-industries/zed/pull/32558
added both `z l` and `z h` to vim mode but it only scrolled the editor's
content, without changing the cursor position. This doesn't reflect the
actual behavior of those motions in vim, so these two commits tackled
that, ensuring that the cursor position is updated, only when the cursor
is on the left or right edges of the editor:
-
ea3b866a76
-
805f41a913
## Horizontal Autoscroll Fix
After introducing the cursor position update to both `z l` and `z h` it
was noted that there was a bug with using `z l`, followed by `0` and
then `z l` again, as on the second use `z l` the cursor would not be
updated. This would only happen on the first line in the editor, and it
was concluded that it was because the
`editor::scroll::autoscroll::Editor.autoscroll_horizontally` method was
directly updating the scroll manager's anchor offset, instead of using
the `editor::scroll::Editor.set_scroll_position_internal` method, like
is being done by the vertical autoscroll
(`editor::scroll::autoscroll::Editor.autoscroll_vertically`).
This wouldn't update the scroll manager's anchor, which would still
think it was at `(0, 1)` so the cursor position would not be updated.
The changes in [this
commit](3957f02e18)
updated the horizontal autoscrolling method to also leverage
`set_scroll_position_internal`.
## Visible Column Count & Page Width Scroll Amount
The changes in
d83652c3ae
add a `visible_column_count` field to `editor::scroll::ScrollManager`
struct, which allowed the introduction of the `ScrollAmount::PageWidth`
enum.
With these changes, two new actions are introduced,
`vim::normal::scroll::HalfPageRight` and
`vim::normal::scroll::HalfPageLeft` (in
7f344304d5),
which move the editor half page to the right and half page to the left,
as well as the cursor position, which have also been mapped to `z
shift-l` and `z shift-h`, respectively.
Closes#17219
Release Notes:
- Improved `z l` and `z h` to actually move the cursor position, similar
to vim's behavior
- Added `z shift-l` and `z shift-h` to scroll half of the page width's
to the right or to the left, respectively
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Might close #33838 for now
Keymaps that work both in vim and helix, but only in normal mode, not
the more general `VimControl` context are written separately. This makes
the file shorter by combining them and also adds one more keymap.
Release Notes:
- N/A
There are both `g q` and `g w` keybinds for rewrapping in normal mode,
but `g w` is missing in visual mode. This PR adds that keybind.
Release Notes:
- Add `g w` rewrap keybind for vim visual mode
Release Notes:
- Added support for vim-mode on git commit editor (modal included)
Side notes:
- Maybe in the future (or even on this PR) a config could be added to
let the user choose whether to enable vim-mode on this editor or not?
And on the agent message editor as well.
In helix the `f`, `F`, `t`, `T`, left and right motions wrap lines. I
added that by default.
Release Notes:
- vim: The `use_multiline_find` setting is replaced by binding to the
correct action in the keymap:
```
"f": ["vim::PushFindForward", { "before": false, "multiline": true }],
"t": ["vim::PushFindForward", { "before": true, "multiline": true }],
"shift-f": ["vim::PushFindBackward", { "after": false, "multiline": true
}],
"shift-t": ["vim::PushFindBackward", { "after": true, "multiline": true
}],
```
- helix: `f`/`t`/`shift-f`/`shift-t`/`h`/`l`/`left`/`right` are now
multiline by default (like helix)
From [this
discussion](https://github.com/zed-industries/zed/discussions/30757).
The default vim keymap already implements some of [vim-unimpaired
keymaps](https://github.com/tpope/vim-unimpaired). I thought I could add
this one as well to move lines up and down.
Since the keymaps are in a plugin and not by default in vim, this might
be out of the scope. If you feel like this is the case, just close the
PR :)
Release Notes:
- vim: Added `[ e` and `] e` key bindings to move lines up and down.
Release Notes:
- Added initial support for both `z l` and `z h` in vim mode
These changes relate to #17219 but don't yet close the issue, as this
Pull Request is simply adding support for horizontal scrolling in vim
mode and actually moving the cursor to the correct column in the current
row will be handled in a different Pull Request.
Some notes on these changes:
- 2 new default keybindings added to vim's keymap
- `z l` which triggers the new `vim::ColumnRight` action
- `z h` which triggers the new `vim::ColumnLeft` action
- Introduced a new `ScrollAmount` variant, `ScrollAmount::Column(f32)`
to represent horizontal scrolling
- Replaced usage of `em_width` with `em_advance` to actually scroll by
the width of the cursor, instead of the width of the character
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
