Vim has both Visual and Select modes. Select mode is similar to Visual mode in some senses, but different in that when a printable character is typed, Vim will replace the selection with that character and continue in Insert mode (similar to how selections work on Notepad or Word or other text editors.)
vmap command creates custom key mappings for both Visual and Select mode.
That's fine if you're mapping a key combination that starts with a non-printable character, such as
<C-y>. But it's problematic when creating a mapping that starts with a printable character, such as
i that are often used for text objects in Visual mode.
The correct way to create such mappings is using
xmap (or, more precisely,
xnoremap, mappings should be created non-recursive whenever possible.)
vmap starts with a
v and Visual mode both starts with a "v" and is entered with the
<C-v> commands, a common mistake is for users to create Visual mode mappings using
vmap, even when they start with printable characters, such as the ones mentioned above or with
<LocalLeader> which are by default and typically set to a printable character (such as
,) as well.
This is of course not helped by Vim users not being very familiar with Select mode, since its use cases are more "niche" and typically Visual mode is the one used interactively. (Select mode is typically used by snippet engines, when highlighting fields that are meant to be replaced as the user types a value for the field.)
So: Why did we get into this situation, in which
vmap also creates mappings for Select mode, even though many (most?) such mappings tend to just break Select mode?
Digging a little bit into the history of it, it seems Visual mode has been present at least since Vim 3.0 (1994, or even earlier.)
Select mode was introduced in Vim 5.2 (August 1998.) At that point,
vmap was reused for Selection mode. (See
smap commands were only introduced in Vim 7 (May 2006.)
I guess the introduction of the separate mapping commands on Vim 7 acknowledges the mistake of reusing the same
vmap mapping for both Visual and Select mode back when the latter was introduced.
But then: Why not have
vmap return to affect Visual mode only and introduce a the new command (
xmap?) to affect both?
Was that perhaps a second mistake in how to handle this (admittedly difficult) situation? I can see the dilemma of how to fix it, since either way you're breaking backwards compatibility... But why fix it this way and not the other way around?