3

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.)

The 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 <F5> or <C-y>. But it's problematic when creating a mapping that starts with a printable character, such as g, or a and 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.)

But since vmap starts with a v and Visual mode both starts with a "v" and is entered with the v, V and <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 <Leader> or <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 :help version5.)

The separate xmap and 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?

Improve this question
2
  • 3
    My guess? Bram (BDFL) valued back-compat over correcting this semantic error. cf. all the cpoptions :)
    – D. Ben Knoble ♦
    Apr 25, 2020 at 21:56
  • 1
    In fact, you have self-answered: 1998-2006 is eight(!) years. So it was too late to fix vmap.
    – Matt
    Apr 26, 2020 at 6:43

1 Answer 1

Reset to default
3

At the time we (maintainers of snippet/template engines) had mappings using :vmap which were targetting the select mode. I still have a few traces of that in my lh-brackets plugin. Also the mswin.vim beasts were using vmap instead of smap, IIRC. I'm not sure if there were other big users of the select mode.

Evolutions that break what is already working, even imperfectly, are not really acceptable. We still have :map and :map!, and yet do they really still make sense?

Improve this answer
2
  • Ah, the snippet engine lobby! 😊 Yeah I think I stopped to consider compatibility issues but didn't spend so much time considering them from the point of view of snippet engines. I thought of it more as "plug-ins will have to change anyways" but that's not really absolutely true, especially since I believe many might have already worked around the quirks and would keep working with vmap. Thanks for bringing up mswin.vim, makes so much sense. And good point about :map itself, suffers from the same issue, and more.
    – filbranden ♦
    Apr 26, 2020 at 17:22
  • 1
    The problem is always around transition times. Almost every day there is something new in vim, and quite often there are changes we (plugin maintainers) have been waiting for ages. While we can control our personal configuration, we cannot control the configuration of end-users. As such, some of us try to provide plugins that still work with older versions of vim -- that would the default version available on widespread OSes (like a RedHat 5 that hasn't completely disappeared yet). If a feature disappears completely without giving us the time to upgrade our code, it would be a nightmare.
    – Luc Hermitte
    Apr 26, 2020 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.