Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vim: visual block 'o' behaves incorrectly with up/down motions #27385

Closed
qgates opened this issue Mar 24, 2025 · 3 comments · Fixed by #27678
Closed

Vim: visual block 'o' behaves incorrectly with up/down motions #27385

qgates opened this issue Mar 24, 2025 · 3 comments · Fixed by #27678
Labels

Comments

@qgates
Copy link

qgates commented Mar 24, 2025

Summary

Visual block mode doesn't behave as vim when using 'o' (move cursor to [o]ther end). Vim moves the cursor to the beginning of the selection allowing use of up/down motions to vertically expand/contract the block selection.

Steps to trigger the problem:

  1. In a block of text lines, enter visual block mode on line 3+
  2. Draw a selection with vim motions
  3. Press 'o'.
  4. Use jk vim motions to grow/shrink the block selection at the top left

Actual Behavior:

Due to zed's multicursor implementation, behaviour isn't as expected, jk resets the block to the RHS column and grows/shrinks the column.

Expected Behavior:

As vim, jk should make the block selection grow/shrink at the top edge.

Zed Version and System Specs

Zed: v0.178.5 (Zed)
OS: Windows 10.0.19045
Memory: 31.8 GiB
Architecture: x86_64

@notpeter notpeter added the vim label Mar 24, 2025
@KyleBarton
Copy link
Contributor

Can reproduce. This might be just an acceptable consequence of doing visual mode a little differently in zed (e.g. multi-cursor mode for visual block mode), but there is at least some inconsistency to note here.

Say you create a multi-cursor context using Alt-click like so:

Image

And then you hit "v" and select a block:

Image

And then you hit "o", followed by "k" to go up a line. The result is that zed essentially takes you to regular visual mode:

Image

Whereas following the steps from @qgates - e.g. control-v, j,j,j,l,l,l,l,o,k produces a different result, even though it seemingly should not be different:

Image

It seems as if this is because the "anchor" cursor is at the top-left in the alt-click case, but on the bottom left in the control-v case. Neither is exactly how native vim's visual block mode would behave, but the alt-click case does seem a bit more intuitive at least.

@KyleBarton
Copy link
Contributor

This is partially a result of a bug in how visual block mode draws its square when "reversed" - e.g. when the cursor is at the beginning of its selection. #27604 addresses that first. Then will look at addressing the o (otherEnd) command with that corrected functionality.

@KyleBarton
Copy link
Contributor

We've now more fully addressed this bug in #27678

ConradIrwin pushed a commit that referenced this issue Mar 28, 2025
Closes #27385

Builds on #27604 so that `vim::OtherEnd` works in visual block mode.
This is accomplished by reversing the order of active selections in the
buffer when the user hit `o`, so that the cursor moves diagonally across
the selection. The current behavior is preserved for `shift-o`, which is
how the cursors behave in vim.

We'll close #27604 since this encapsulates that change, but if you'd
prefer to take only the visual block motion component, we'll keep the
branch for #27604 open.

Test case: growing a box down and to the right, other ending, followed
by growing and shrinking the box:


https://github.com/user-attachments/assets/1df544e1-efce-4354-b354-bbfec007a7df

Test case: growing a box up and to the left, other ending, followed by
growing and shrinking the box:


https://github.com/user-attachments/assets/2f6d7729-c63a-4486-960b-23474c2e507a



Release Notes:
- Improved visual block mode when cursor is at beginning of selection
- Improved visual block mode so that `o` and `shift-o` reach parity with
vim

---------

Co-authored-by: KyleBarton <kjbarton4@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants