Today’s quick post is about why Vim plugin writers should generally use “no remap” versions of keyboard mappings.

Check out this StackOverflow post for a great overview of how mapping works. Basically, using :map a b will map presses of key a to whatever b currently does. However, using :noremap a b will translate presses of key a to whatever b did by default.

There are variants of these commands, such as nnoremap and vnoremap which only change the mappings in normal and visual mode, respectively.

Plugin creators should use noremap versions because they can never assume that users will not remap their keys.

Some handy tricks that might be perilous

One thing that I currently use in my .vimrc and miss when it is not present is:

noremap ; :
noremap : ;

This sets the semicolon to enter command-mode (what colon typically does) and sets the colon operator to search forward on the line for the search character (what semicolon does by default.)

This saves me unknown amounts of shift-pressing, and I think it is very useful. However, when I run into a plugin that does something like:

nmap <leader>cf :let @*=expand("%")<CR>

My editor would not work quite right. This is because without using the no-recursive version of remap, Vim will interpret the colon as the colon to search forward, not the colon to enter command-mode (the default behavior.) If we instead say:

nnoremap <leader>cf :let @*=expand("%")<CR>

Then plugins work just fine even though I have remapped a seemingly critical key.