Rethinking Visual and Operator-pending keymaps

[ggandor]

My proposal is really simple. In Visual and Operator-pending mode:

x = current x
X = current Z

That is,

ab···|                     |···ab
█████·  ←   Xab   xab   →  ██████
██████  ←  vXab   vxab  →  █████·

If you have the default keymaps already set, you can try this out with:

vim.keymap.set({'x', 'o'}, 'x', '<Plug>(leap-forward-x)')
vim.keymap.set({'x', 'o'}, 'X', '<Plug>(leap-backward)')
vim.keymap.del('x', 's')
vim.keymap.del('x', 'S')
vim.keymap.del('o', 'z')
vim.keymap.del('o', 'Z')

Pro

• Having one pair instead of two means less cognitive load, which we naturally appreciate; "one obvious way to do things" is liberating - honestly, sometimes I still pause for a fraction of a second when wanting to use z/Z/x/X. vz = vx makes it even more awkward. I think this is the most important point and the strongest argument in favor of rethinking the current arrangement.

Why keep the "inclusive" pair?

• forward/+1/inclusive can extend selections till EOL, i.e., it is always applicable, while forward/+0 is not. Symmetry is also an advantage. For example, you would select a rectangular block from the top-left and the bottom-right corner using the same pair.
• Leap motions can indeed be thought of as shortcuts for /?, but since the pattern length is fixed, it is just as, if not more intuitive to think about the matches as solid chunks, and include them in the selection.

Cons

• Consistency with /? also has its logic.
• No mnemonics for x/X anymore (not even the "geometric" one on QWERTY, i.e., being the right neighbour of z/Z).

Regarding the choice of x/X:

Pro

• x/X do not conflict with (n)vim-surround at all, even in Visual mode (yay!). (Also, visual surround can use s/S instead of its default gs/S, and can be fully consistent, since we're taking over the native s/S anyway.)

Con

• Well, muscle memory of course. I guess most people learned to use x instead of d for visual deletion.

Fact

• z cannot be used in Visual mode (native fold operations). s cannot really be used in operator-pending mode (surround plugins use it, and rightly so). So x remains.

[ggandor]

One edge case that seems impossible without a "backward-exclusive" motion (current X) is:

xxx\n
<target>\n
...
yyy<cursor>zzz\n

resulting in

xxx\n
zzz\n

That is, targeting an empty line, but not as a linewise motion. Not terribly frequent, and probably doesn't matter much in practice, but an annoying, ugly gap nevertheless.

[ggandor]

Proposal no. 2:

Use evil-snipe's arrangement (basically just switch our x and z):

abcd|                    |bcde
████e  ←  Zab    zde  →  █████    (this might also be the desired behavior for Visual `s` - see below)
ab██e  ←  Xab    xde  →  ███de

Note: vim-seek also uses x/X the same way. "Exclusive" is definitely the most obvious mnemonic for these keys, it's hard to argue with that.

I've also grown to like evil-snipe's "end-inclusive" s mapping in Visual mode (behaves like z above - i.e., our current forward-x). It's not ideal that it behaves differently than in Normal mode, but in my experience one would almost always want to either include the full match or exclude it completely. Having to give one "follow-up" character after the end of the intended selection is rarely intuitive in Visual mode.