Closes#24820
This PR fixes the bug specified in issue
https://github.com/zed-industries/zed/issues/24820, now the matching
function checks if the cursor is above a comment or a directive before
defaulting to a bracket range as neovim does.
It also fixes fixes the `line_end` calculations so that when `%` is
pressed inside a bracket range
https://github.com/user-attachments/assets/f59daa6f-9769-45e8-bb8c-2d533470b59d
Release Notes:
- `fn matching()` checks for `preprocessor directives` or `comments`
before defaulting to any bracket range.
- In `fn matching()`line_end calculations avoid expanding a blank
current line into start..EOF.
Implements:
[49806](https://github.com/zed-industries/zed/discussions/49806)
Closes: [24820](https://github.com/zed-industries/zed/issues/24820)
Zeds impl of `%` didn't handle preprocessor directives and multiline
To implement this feature for multiline comment, a tree-sitter query is
used to check if we are inside a comment range
and then replicate the logic used in brackets.
For preprocessor directives using `TextObjects` wasn't a option, so it
was implemented through a text based query
that searches for the next preprocessor directives. Using text based
queries might not be the best for performance, so I'm open to any
suggestions.
Release Notes:
- Fixed vim's matching '%' to handle multiline comments `/* */` and
preprocessor directives `#if #else #endif`.
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>
Update Helix's handling of the following actions in order to ensure that
selections are created when using subword motions:
* `vim::NextSubwordStart`
* `vim::NextSubwordEnd`
* `vim::PreviousSubwordStart`
* `vim::PreviousSubwordEnd`
The handling of these motions was done by
`vim::helix::Vim::helix_move_and_collapse`, which simply moved the
cursor without doing any selection. This commit updates it to correctly
use both `vim::helix::Vim::helix_find_range_forward` and
`vim::helix::Vim::helix_find_range_backward`.
The added tests have been confirmed against Helix's behavior of the following commands:
* `move_next_sub_word_start`
* `move_prev_sub_word_start`
* `move_next_sub_word_end`
* `move_prev_sub_word_end`
Closes#41767
Release Notes:
- Fix subword motions in Helix mode to select traversed text
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
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 ...
Reverts the editor's paragraph navigation behavior that was changed in
#47734. Whitespace-only lines are now treated as paragraph boundaries
again for non-vim mode users.
Vim mode retains its own implementation where only truly empty lines
are paragraph boundaries.
Release Notes:
- Fixed editor paragraph navigation to treat whitespace-only lines as
paragraph boundaries again
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
When using `$` to move to the end of line (`vim::EndOfLine`), the
`vim::motion::Motion.move_point` method checks whether the new point,
that is, the point after the motion is applied is different from the
point that was passed as a method argument. If the point is not
different, the point and selection goals are only updated if
`vim::motion::Motion.infallible` returns true for the motion in
question.
In short, this means that, if the cursor was already at the end of the
line, and it got there using `vim::Right`, for example, the selection
goal wouldn't actually be set to
`SelectionGoal::HorizontalPosition(f64::INFINITY)`, so when the cursor
was moved to a shorter line, it wouldn't be set at the end of that line,
even though `$` had been used.
This commit updates `vim::motion::Motion.infallible` to ensure that, for
`vim::motion::Motion::EndOfLine`, it returns `true`, so that the
selection goal is always updated, regardless of whether the cursor is
already at the end of the line.
Closes#48855
- [X] Tests or screenshots needed?
- [X] Code Reviewed
- [X] Manual QA
Release Notes:
- vim: Fixed `$` not sticking to end-of-line on vertical motions
(`j`/`k`) when the cursor was already at the end of the line via `l` or
arrow keys
These changes update subword motions in order to also take `$` and `=`
into consideration as stopping punctuation, improving the subword
motions for certain languages where `$` and `=` are commonly used, like
PHP, for variables and assignments.
Closes#48267
Release Notes:
- Improved Vim's subword motions to stop at `$` and `=` characters
Previously, `]m`/`[m` (method) and `]/`/`[/` (comment) motions would
navigate to incorrect positions when diff hunks were expanded. This was
caused by extracting raw `usize` values from `MultiBufferOffset` and
operating directly on the underlying buffer, which doesn't account for
expanded diff hunk content.
The fix properly uses `MultiBufferOffset` throughout and queries
`text_object_ranges` on the `MultiBufferSnapshot` instead of the
underlying buffer, ensuring correct coordinate mapping when diff content
is displayed inline.
Fixes#46612
Release Notes:
- Fixed vim method and comment navigation (`] m`, `[ m`, `] shift-m`, `[
shift-m`, `] /`, `[ /`) incorrectly positioning cursor when diff hunks
are expanded
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: dino <dinojoaocosta@gmail.com>
- 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>
The `}` and `{` paragraph motions now correctly treat only truly empty
lines (zero characters) as paragraph boundaries, matching vim's
documented behavior. Whitespace-only lines are no longer treated as
boundaries.
Changed `start_of_paragraph()` and `end_of_paragraph()` in
`editor/src/movement.rs` to check `line_len() == 0` instead of
`is_line_blank()`.
Note: This change does NOT affect the `ap`/`ip` text objects. Per vim's
`:help ap`, those DO treat whitespace-only lines as boundaries, which is
the existing (correct) behavior in `vim/src/object.rs`.
Closes#36171
Release Notes:
- Fixed vim mode paragraph motions (`}` and `{`) to correctly ignore
whitespace-only lines
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
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>
Add a `match_quotes` parameter to the `vim::Matching` action that
controls whether the `%` motion should treat quote characters (', ", `)
as matching pairs.
In Neovim, `%` only matches bracket pairs (([{}])), not quotes. Zed's
existing behavior includes quote matching, which some users prefer. To
preserve backwards compatibility while allowing users to opt into
Neovim's behavior, this PR:
1. Adds an optional `match_quotes` boolean parameter to the
`vim::Matching` action
2. Updates the default vim keymap to use ["vim::Matching", {
"match_quotes": true }], preserving Zed's current behavior
3. Users who prefer Neovim's behavior can rebind `%` in their keymap:
```
{
"context": "VimControl && !menu",
"bindings": {
"%": ["vim::Matching", { "match_quotes": false }]
}
}
```
When `match_quotes` is `false`, the `%` motion will skip over quote
characters and only match brackets/parentheses, matching Neovim's
default behavior.
Release Notes:
- vim: Added match_quotes parameter to the vim::Matching action to control
whether % matches quote characters
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes#45340
Release Notes:
- Fixed $ motion in vim mode to stay at end of the line when moving
vertically
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes#41582
Release Notes:
- Improves the '%' vim motion for html by moving the cursor to the
opening tag when its positioned on the `/` ( slash ) of the closing tag
It is easy for us to get the two fields out of sync causing weird
problems, there is no reason to have both here so.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Co-authored by: Antonio Scandurra <antonio@zed.dev>
This PR introduces a new `MultiBufferOffset` new type wrapping size. The
goal of this is to make it clear at the type level when we are
interacting with offsets of a multi buffer versus offsets of a language
/ text buffer. This improves readability of things quite a bit by making
it clear what kind of offsets one is working with while also reducing
accidental bugs by using the wrong kin of offset for the wrong API.
This PR also uncovered two minor bugs due to that.
Does not yet introduce the MultiBufferPoint equivalent, that is for a
follow up PR.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This PR redoes the desired behavior changes of #41583 (reverted in
#42892) but less invasively
Closes#41125Closes#41164
Release Notes:
- N/A
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
We now correctly use bracket ranges from the deepest syntax layer when
finding enclosing brackets.
Release Notes:
- Fixed an issue where `MoveToEnclosingBracket` didn’t work correctly
inside Markdown code blocks.
- Fixed an issue where unmatched forward/backward Vim motions didn’t
work correctly inside Markdown code blocks.
---------
Co-authored-by: MuskanPaliwal <muskan10112002@gmail.com>
Closes#41125
Release Notes:
- Fixed `SwitchToHelixNormalMode` to keep selection
- Added default keybinds for `SwitchToHelixNormalMode` when in Helix
mode
Closes https://github.com/zed-industries/zed/issues/40047
Closes https://github.com/zed-industries/zed/issues/24798
Closes https://github.com/zed-industries/zed/issues/24788
Before, each editor, even if it's the same buffer split in 2, was
querying for inlay hints separately, and storing the whole inlay hint
twice, in `Editor`'s `display_map` and its `inlay_hint_cache` fields.
Now, instead of `inlay_hint_cache`, each editor maintains a minimal set
of metadata (which area was queried by what task) instead, and all LSP
inlay hint data had been moved into `LspStore`, both local and remote
flavors store the data.
This allows Zed, as long as a buffer is open, to reuse the inlay hint
data similar to how document colors and code lens are now stored and
reused.
Unlike other reused LSP data, inlay hints data is the first one that's
possible to query by document ranges and previous version had issue with
caching and invalidating such ranges already queried for.
The new version re-approaches this by chunking the file into row ranges,
which are queried based on the editors' visible area.
Among the corresponding refactoring, one notable difference in inlays
display are multi buffers: buffers in them are not
[registered](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didOpen)
in the language server until a caret/selection is placed inside their
excerpts inside the multi buffer.
New inlays code does not query language servers for unregistered
buffers, as servers usually respond with empty responses or errors in
such cases.
Release Notes:
- Reworked inlay hints to be less error-prone
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Co-authored-by: dino <dinojoaocosta@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
- 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>
Update Vim's `%` motion to first attempt finding the exact matching
bracket/tag under the cursor, then fall back to the previous
nearest-enclosing logic if none is found. This prevents accidentally
jumping to nested pairs in languages like TSX and Svelte where `<>`,
`</>`, and `/>` are also treated as brackets.
Closes#39368
Release Notes:
- Fixed an edge case with the `%` motion in vim, where the cursor could
end up in a closing HTML tag instead of the matching bracket
We have unnecessary clones for the fields here as most of the snapshots
contain the others hierarchically.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
These changes fix an issue with vim's visual block mode when soft
wrapping is enabled. In this situation, if one was to move the cursor
either up or down, the selection would be updated to include visual
(wrapped) rows, instead of only the buffer rows. For example, take the
following contents:
```
1 | And here's a very long line that is wrapping
at this exact point.
2 | And another very long line that is will also
wrap at this exact point.
```
If one was to place the cursor at the start of the first line, character
`A`, trigger visual block mode with `ctrl-v` and then move down one line
with `j`, the selection would end up as (with [X] representing the
selected characters):
```
1 | [A]nd here's a very long line that is wrapping
[a]t this exact point.
2 | [A]nd another very long line that is will also
wrap at this exact point.
```
Instead of the expected:
```
1 | [A]nd here's a very long line that is wrapping
at this exact point.
2 | [A]nd another very long line that is will also
wrap at this exact point.
```
With the changes in this commit, `Vim.visual_block_motion` will now
leverage buffer rows in order to navigate to the next or previous row.
Release Notes:
- Fixed handling of soft wrapped lines in vim's visual block mode
Closes#5355
Release Notes:
- Fixed rendering glitches with files with more than 16 million lines
(that occured due to floating number rounding errors).
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.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>
**Summary**
Fixes#29134 - Visual mode cursor incorrectly jumps past empty lines
that contain inlay hints (type hints).
**Problem**
When in VIM visual mode, pressing j to move down from a longer line to
an empty line that contains an inlay hint would cause the cursor to skip
the empty line entirely and jump to the next line. This only occurred
when moving down (not up) and only in visual mode.
**Root Cause**
The issue was introduced by commit f9ee28db5e which added bias-based
navigation for handling multi-line inlay hints. When using Bias::Right
while moving down, the clipping logic would place the cursor past the
inlay hint, causing it to jump to the next line.
**Solution**
Added logic in up_down_buffer_rows to detect when clipping would place
the cursor within an inlay hint position. When detected, it uses the
buffer column position instead of the display column to avoid jumping
past the hint.
**Testing**
- Added comprehensive test case
test_visual_mode_with_inlay_hints_on_empty_line that reproduces the
exact scenario
- Manually verified the fix with the reproduction case from the issue
- All 356 tests pass with `cargo test -p vim`
**Release Notes:**
- Fixed VIM visual mode cursor jumping past empty lines with type hints
when navigating down
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
In vim and zed (vim and helix modes) typing "tx" will jump before the
next `x`, but typing it again won't do anything. But in helix the cursor
just jumps before the `x` after that. I added that in helix mode.
This also solves another small issue where the selection doesn't include
the first `x` after typing "fx" twice. And similarly after typing "Fx"
or "Tx" the selection should include the character that the motion
startet on.
Release Notes:
- helix: Fixed inconsistencies in the "f" and "t" motions
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.
Instead of a menagerie of macros for implementing `Action`, now there
are just two:
* `actions!(editor, [MoveLeft, MoveRight])`
* `#[derive(..., Action)]` with `#[action(namespace = editor)]`
In both contexts, `///` doc comments can be provided and will be used in
`JsonSchema`.
In both contexts, parameters can provided in `#[action(...)]`:
- `namespace = some_namespace` sets the namespace. In Zed this is
required.
- `name = "ActionName"` overrides the action's name. This must not
contain "::".
- `no_json` causes the `build` method to always error and
`action_json_schema` to return `None`
and allows actions not implement `serde::Serialize` and
`schemars::JsonSchema`.
- `no_register` skips registering the action. This is useful for
implementing the `Action` trait
while not supporting invocation by name or JSON deserialization.
- `deprecated_aliases = ["editor::SomeAction"]` specifies deprecated old
names for the action.
These action names should *not* correspond to any actions that are
registered. These old names
can then still be used to refer to invoke this action. In Zed, the
keymap JSON schema will
accept these old names and provide warnings.
- `deprecated = "Message about why this action is deprecation"`
specifies a deprecation message.
In Zed, the keymap JSON schema will cause this to be displayed as a
warning. This is a new feature.
Also makes the following changes since this seems like a good time to
make breaking changes:
* In `zed.rs` tests adds a test with an explicit list of namespaces. The
rationale for this is that there is otherwise no checking of `namespace
= ...` attributes.
* `Action::debug_name` renamed to `name_for_type`, since its only
difference with `name` was that it
* `Action::name` now returns `&'static str` instead of `&str` to match
the return of `name_for_type`. This makes the action trait more limited,
but the code was already assuming that `name_for_type` is the same as
`name`, and it requires `&'static`. So really this just makes the trait
harder to misuse.
* Various action reflection methods now use `&'static str` instead of
`SharedString`.
Release Notes:
- N/A
