## Summary
Closes#53570
- `o` and `O` in normal mode were unconditionally copying the current
line's indentation into the new line, ignoring the `auto_indent` setting
entirely
- When `auto_indent: "none"` is set, new lines created by `o`/`O` now
start at column 0 as expected
- When `auto_indent` is `preserve_indent` or `syntax_aware`, behavior is
unchanged
The fix reads `language_settings_at` for the relevant row and splits
edits into two paths: `editor.edit()` (no autoindent) for `None`, and
`editor.edit_with_autoindent()` for everything else — mirroring the
approach already used by the non-vim `Newline` action.
## Test plan
- Added `test_o_auto_indent_none`: verifies `o`/`O` produce column-0
lines with `auto_indent: "none"`, including edge cases (first line,
empty line)
- Added `test_o_preserve_indent`: verifies `o`/`O` copy the current
line's indentation with `auto_indent: "preserve_indent"` (regression
guard)
- Existing neovim-backed tests (`test_o`, `test_insert_line_above`,
`test_o_comment`) continue to pass
Release Notes:
- Fixed vim `o`/`O` commands ignoring the `auto_indent: "none"` setting,
causing new lines to inherit indentation instead of starting at column 0
## Context
Closes#46698
This PR fixes a bug where the `cs` (change surrounds) operator fails on
symmetric delimiters like quotes.
In a sequence like `c s ' "`, Zed previously performed two independent
searches. For a line like `I'm 'goˇod'`, the first step (`cs'`)
correctly moves the cursor to the second quote: `I'm ˇ'good'`. However,
when the replacement character `"` is pressed, `change_surrounds` would
perform another scan from the new cursor position. Because quotes are
symmetric, this second search would incorrectly match `'m '` as the
target pair, leading to a broken result like `I"m "good'`.
I've refactored the workflow to ensure the search happens only once.
`prepare_and_move_to_valid_bracket_pair` now computes and stores the
`Anchor` positions of the detected pair directly into the operator
state. `change_surrounds` then simply reuses these anchors instead of
re-executing the search. This ensures correctness for quotes while
remaining consistent with Vim/Neovim cursor behavior. While this
slightly increases coupling between these two functions, it is an
intentional trade-off since they exclusively serve the `cs` operation.
## How to Review
The main changes are in `crates/vim/src/surrounds.rs`. I renamed
`check_and_move_to_valid_bracket_pair` to
`prepare_and_move_to_valid_bracket_pair` and updated it to return the
detected bracket anchors. In `change_surrounds`, I removed the redundant
search logic and updated it to perform the replacement using the
provided anchors. You can also see the updated
`Operator::ChangeSurrounds` enum variant in `crates/vim/src/state.rs`
which now carries the anchor data.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- Fixed an issue where the `cs` Vim operator incorrectly identified
symmetric quotes in certain contexts.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Closes#4751
## Testing
- Manually tested by comparing the behaviors with vscode.
- Those requirements are added to unit tests.
Release Notes:
- Added action to toggle block comments
---------
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
TODO:
- [x] merge main
- [x] nonshrinking `set_excerpts_for_path`
- [x] Test-drive potential problem areas in the app
- [x] prepare cloud side
- [x] test collaboration
- [ ] docstrings
- [ ] ???
## Context
### Background
Currently, a multibuffer consists of an arbitrary list of
anchor-delimited excerpts from individual buffers. Excerpt ranges for a
fixed buffer are permitted to overlap, and can appear in any order in
the multibuffer, possibly separated by excerpts from other buffers.
However, in practice all code that constructs multibuffers does so using
the APIs defined in the `path_key` submodule of the `multi_buffer` crate
(`set_excerpts_for_path` etc.) If you only use these APIs, the resulting
multibuffer will maintain the following invariants:
- All excerpts for the same buffer appear contiguously in the
multibuffer
- Excerpts for the same buffer cannot overlap
- Excerpts for the same buffer appear in order
- The placement of the excerpts for a specific buffer in the multibuffer
are determined by the `PathKey` passed to `set_excerpts_for_path`. There
is exactly one `PathKey` per buffer in the multibuffer
### Purpose of this PR
This PR changes the multibuffer so that the invariants maintained by the
`path_key` APIs *always* hold. It's no longer possible to construct a
multibuffer with overlapping excerpts, etc. The APIs that permitted
this, like `insert_excerpts_with_ids_after`, have been removed in favor
of the `path_key` suite.
The main upshot of this is that given a `text::Anchor` and a
multibuffer, it's possible to efficiently figure out the unique excerpt
that includes that anchor, if any:
```
impl MultiBufferSnapshot {
fn buffer_anchor_to_anchor(&self, anchor: text::Anchor) -> Option<multi_buffer::Anchor>;
}
```
And in the other direction, given a `multi_buffer::Anchor`, we can look
at its `text::Anchor` to locate the excerpt that contains it. That means
we don't need an `ExcerptId` to create or resolve
`multi_buffer::Anchor`, and in fact we can delete `ExcerptId` entirely,
so that excerpts no longer have any identity outside their
`Range<text::Anchor>`.
There are a large number of changes to `editor` and other downstream
crates as a result of removing `ExcerptId` and multibuffer APIs that
assumed it.
### Other changes
There are some other improvements that are not immediate consequences of
that big change, but helped make it smoother. Notably:
- The `buffer_id` field of `text::Anchor` is no longer optional.
`text::Anchor::{MIN, MAX}` have been removed in favor of
`min_for_buffer`, etc.
- `multi_buffer::Anchor` is now a three-variant enum (inlined slightly):
```
enum Anchor {
Min,
Excerpt {
text_anchor: text::Anchor,
path_key_index: PathKeyIndex,
diff_base_anchor: Option<text::Anchor>,
},
Max,
}
```
That means it's no longer possible to unconditionally access the
`text_anchor` field, which is good because most of the places that were
doing that were buggy for min/max! Instead, we have a new API that
correctly resolves min/max to the start of the first excerpt or the end
of the last excerpt:
```
impl MultiBufferSnapshot {
fn anchor_to_buffer_anchor(&self, anchor: multi_buffer::Anchor) -> Option<text::Anchor>;
}
```
- `MultiBufferExcerpt` has been removed in favor of a new
`map_excerpt_ranges` API directly on `MultiBufferSnapshot`.
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Co-authored-by: Conrad <conrad@zed.dev>
Fix Helix `o`/`O` behavior when a selection is active.
This updates `InsertLineAbove` and `InsertLineBelow` to use the
selection bounds correctly for Helix selections, including line
selections whose end is represented at column 0 of the following line.
It also adds Helix select-mode keybindings for `o` and `O`, and adds
tests covering both line selections and selections created via `v`.
Closes#43210
Release Notes:
- helix: Fixed insert line above/below behavior when a full line is
selected
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
When a command used an explicit register (e.g. `"_dd` or `"add`), the
subsequent dot repeat (`.`) was ignoring that register and using the
default instead.
Store the register at recording start in `recording_register_for_dot`,
persist it to `recorded_register_for_dot` when recording stops, and
restore it in `Vim::repeat` when no explicit register is supplied for
`.`. An explicit register on `.` (e.g. `"b.`) still takes precedence.
This commit also updates the dot-repeat logic to closely follow Neovim's
when using numbered registers, where each dot repeat increments the
register. For example, after using `"1p`, using `.` will repeat the
command using `"2p`, `"3p`, etc.
Closes#49867
Release Notes:
- Fixed vim's repeat . to preserve the register the recorded command
used
- Updated vim's repeat . to increment the recorded register when using
numbered registers
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Replaces a bunch of `impl FnMut` parameters with `&mut dyn FnMut` for
functions where this is the sole generic parameter.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
- Remove old attempt to sync scrolling
- Share a `ScrollAnchor` between the two sides, and be sure to resolve
it against the correct snapshot
- Allow either side to initiate an autoscroll request, and make sure
that request is processed in the same frame by the other side
Release Notes:
- N/A
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: Jakub <jakub@zed.dev>
Thanks @injust for pointing this out. It seems a few other action docs
were also copied from elsewhere and weren't updated to reflect their
actual purpose. This PR fixes those, though I may not have covered all
of them.
Closes#46832
Release Notes:
- N/A
---------
Co-authored-by: Kunall Banerjee <hey@kimchiii.space>
Fixes subword motion incorrectly jumping to next line when near end of
line. Updates boundary detection to use exclusive boundaries with
need_next_char parameter, matching regular word motion behavior.
Refactors word and subword motion to share boundary detection logic.
Closes#17780
Release Notes:
- Fixed subword motion incorrectly jumping to the next line when near
the end of a line
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
The `Vim.exit_temporary_normal` method had been updated
(https://github.com/zed-industries/zed/pull/42742) to expect and
`Option<&Motion>` that would then be used to determine whether to move
the cursor right in case the motion was `Some(EndOfLine { ..})`.
Unfortunately this meant that all callers now had to provide this
argument, even if just `None`.
After merging those changes I remember that we could probably play
around with `clip_at_line_ends` so this commit removes those intial
changes in favor of updating the `vim::normal::Vim.move_cursor` method
so that, if vim is in temporary mode and `EndOfLine` is used, it
disables clipping at line ends so that the newline character can be
selected.
Closes [#42278](https://github.com/zed-industries/zed/issues/42278)
Release Notes:
- N/A
When using the end of line motion ($) while in temporary mode, the
cursor would be placed in insert mode just before the last character
instead of after, just like in NeoVim.
This happens because `EndOfLine` kind of assumes that we're in `Normal`
mode and simply places the cursor in the last character instead of the
newline character.
This commit moves the cursor one position to the right when exiting
temporary mode and the motion used was `Motion::EndOfLine`
- Update `vim::normal::Vim.exit_temporary_normal` to now accept a
`Option<&Motion>` argument, in case callers want this new logic to
potentially be applied
Closes#42278
Release Notes:
- Fixed temporary mode exit when using `$` to move to the end of the
line
- Update `vim::normal::Vim.normal_replace` to work with more than one
character
- Add `vim::replace::Vim.paste_replace` to handle pasting the
clipboard's contents while in replace mode
- Update vim's handling of the `editor::actions::Paste` action so that
the `paste_replace` method is called when vim is in replace mode,
otherwise it'll just call the regular `editor::Editor.paste` method
Closes#41378
Release Notes:
- Improved pasting while in Vim's Replace mode, ensuring that the Zed
replaces the same number of characters as the length of the contents
being pasted
Re-applies https://github.com/zed-industries/zed/pull/30840
This PR re-applies the initial
[PR](https://github.com/zed-industries/zed/pull/30840). As it was closed
because it was hard to land, because of the many conflicts. This PR
re-applies the changes for it.
In several cases we were creating multiple display_map
snapshots within the same root-level function call.
Creating a display_map snapshot is quite slow, and in some
cases we were creating the snapshot multiple times.
Release Notes:
- N/A
- 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>
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.
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
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.
Co-Authored-By: Ben K <ben@zed.dev>
Co-Authored-By: Anthony <anthony@zed.dev>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Release Notes:
- settings: Major internal changes to settings. The primary user-facing
effect is that some settings which did not make sense in project
settings files are no-longer read from there. (For example the inline
blame settings)
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
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#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
Currently, the HelixDelete action switches to (vim) Normal mode instead
of HelixNormal mode. This adds a line to the helix delete action to stay
in helix normal mode.
There was already a commented-out test for this. I've uncommented it and
it now passes.
Release Notes:
- helix: Fixed switching to vim NORMAL mode instead of HELIX_NORMAL mode
after deletion
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
Closes #ISSUE
Adds a new `documentation` method to actions, that is extracted from doc
comments when using the `actions!` or derive macros.
Additionally, this PR adds doc comments to as many action definitions in
Zed as possible.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
In #32656 I generalized the argument to change selections to allow
controling both the scroll and the nav history (and the completion
trigger).
To avoid conflicting with ongoing debugger cherry-picks I left the
argument as an `impl Into<>`, but I think it's clearer to make callers
specify what they want here.
I converted a lot of `None` arguments to `SelectionEffects::no_scroll()`
to be exactly compatible; but I think many people used none as an "i
don't care" value in which case Default::default() might be more
appropraite
Closes #ISSUE
Release Notes:
- N/A
In #32656 I generalized the argument to change selections to allow
controling both the scroll and the nav history (and the completion
trigger).
To avoid conflicting with ongoing debugger cherry-picks I left the
argument as an `impl Into<>`, but I think it's clearer to make callers
specify what they want here.
I converted a lot of `None` arguments to `SelectionEffects::no_scroll()`
to be exactly compatible; but I think many people used none as an "i
don't care" value in which case Default::default() might be more
appropraite
Closes#23527Closes#30183
Closes some Discord chats
Release Notes:
- vim: Motions now push to the jump list using the same logic as vim
(i.e.
`G`/`g g`/`g d` always do, but `j`/`k` always don't). Most non-vim
actions
(including clicking with the mouse) continue to push to the jump list
only
when they move the cursor by 10 or more lines.
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)
Fixes:
`] space` does not consume counts, and it gets applied to the next
action.
`] space` on an empty line causes cursor to move to the next line.
Release Notes:
- N/A
Release Notes:
- `r enter` now maintains indentation, matching vim
Useful info for this implementation can be found here:
c3f48e3a76/src/normal.c (L4865)
This brings in a bunch of helix bindings (many of them from
infogulch/zed-helix-keymap) and implements helix-style delete.
Release Notes:
- vim: Expanded default helix-style keybindings in HelixNormal mode
Closes https://github.com/zed-industries/zed/issues/13111
Release Notes:
- vim: Added global marks `'[A-Z]`
- vim: Added persistence for global (and local) marks. When re-opening
the same workspace your previous marks will be available.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
