vim key mapping being fired by carriage return

Question

I use gvim on windows 10 and am trying to get a good keymap to open a vertical split to a new file. I first tried

nnoremap <c-m><c-m> :vnew<CR>

but for some reason if I hit carriage return twice in succession in normal mode, I would get a new vertical split window. So I took the trailing carriage return out of the key map

nnoremap <c-m><c-m> :vnew

and still get a new vertical split window if I hit carriage return three times in normal mode, which for some reason I find myself doing.

Why is carriage return setting off the key map when there isn't even a carriage return in the key map in _vimrc? I have restarted vim with no effect.

Answer 1

From Vim's point of view, <C-m> is <CR> and <CR> is <C-m>.

They are the same key so you can't map something to <C-m> without mapping it to <CR> and vice-versa.

You'll need to find another key combo for your mapping.

Answer 2

Due to the way that the keyboard input is handled internally, this unfortunately isn't generally possible today, even in GVIM. Some key combinations, like Ctrl + non-alphabetic cannot be mapped, and Ctrl + letter vs. Ctrl + Shift + letter cannot be distinguished. (Unless your terminal sends a distinct termcap code for it, which most don't.) In insert or command-line mode, try typing the key combination. If nothing happens / is inserted, you cannot use that key combination. This also applies to <Tab> / <C-I>, <CR> / <C-M> / <Esc> / <C-[> etc. (Only exception is <BS> / <C-H>.) This is a known pain point, and the subject of various discussions on vim_dev and the #vim IRC channel.

Some people (foremost Paul LeoNerd Evans) want to fix that (even for console Vim in terminals that support this), and have floated various proposals, cp. http://groups.google.com/group/vim_dev/browse_thread/thread/626e83fa4588b32a/bfbcb22f37a8a1f8

But as of today, no patches or volunteers have yet come forward, though many have expressed a desire to have this in a future Vim release.