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

[qgates]

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

[KyleBarton]

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:

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

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:

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:

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]

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]

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