Why does terminal vim enter replace mode with my vimrc file?

Question

I mostly use MacVim, but sometimes I'm in the terminal and use the CLI vim.

I recently decided to clean up my vimrc file, retaining only what I knew I wanted. It works fine with MacVim, but when I launch vim from the terminal, it works, but does two things MacVim doesn't:

• Beeps
• Places me in Replace mode

D. Ben Knoble helped me track down that it has to do with the following line:

nnoremap <ESC> :nohlsearch<RETURN><ESC>

When I remove that line, the problem does disappear. But I do like the behavior it gives me (removing highlighted searches when I hit <ESC>).

So, why does that line cause the problem, and is there a way to get what I want with it that doesn't cause a problem?

Here's my vimrc file on GitHub:

Answer 1

If you are seeing a similar issue and using Windows Terminal jump down to the "Update" below.

Seeing <ESC> used as the LHS of a key mapping causes me some discomfort. You've demonstrated one reason why...it doesn't seem to work right in a vimrc file. It doesn't matter what you have on the RHS, the LHS <ESC> causes some characters (maybe related to the underlying key code for <ESC>) to be emitted as if they were Normal mode commands and those include 2R. (If you type something right after entering Vim and hit escape you'll see the typed string replace current text twice.)

My first bit of advice would be to save the headaches and use a different key for mapping. If you really want to use <ESC> then continue...

My first instinct while trying to fix things was to use an autocommand to delay the setup of the mapping but that doesn't help. It's still in the context that doesn't play nice with LHS <ESC>

My second notion was to also use an autocommand but with an asynchronous call since these calls occur in a different context (i.e. when Vim's thread has entered an idle state). Turns out, it works...

func! EscMapSetup(timerid)
    nnoremap <ESC> :nohlsearch<CR><ESC>
endfunc
autocmd VimEnter * call timer_start(100, 'EscMapSetup')

Has that hack smell to it but if someone can't come up with the root cause of this issue and a clean way around it this isn't too bad...at least it doesn't require any particular timing; the 100ms above is an arbitrarily chosen number of short duration.

BTW... What is the purpose of the <ESC> on the RHS of the mapping? You're already in Normal mode so it doesn't do anything there. Only thing I can think of is you want to clear the command line of the nohlsearch text that lingers there. If so, consider using <C-L> in it's place. That will redraw the screen after cleaning it...that leaves a pristine c/l...and no more flirting with problems that the special status of <ESC> sometimes bears.

2020-12-05 Update: Per the numerous comments below Command already typed in when I open vim there is a bug, since fixed and released in September, in the Windows Terminal terminal emulator.

You can either get the latest version of WT or you can try an alternate terminal emulator. I personally use and like mintty.

There is also a workaround that appears to be benign: :set t_u7=

In short the problem is how WT handles the control sequence contained in 't_u7'. This control sequence, valid only for xterm-compatible terminal emulators, is used to get the cursor's position. Vim sends the sequence to the terminal on startup under certain conditions (i.e. if using utf-8 'encoding' or similar) to find out how wide characters are represented. When WT responds it mixes the answer with the response to a separate control sequence such that individual characters are intermingled rendering the whole thing invalid and causing Vim to think it's normal user input. It so happens that the last two characters are usually 2R which explains why things behave as if you entered that Normal mode command.

See also

• Windows Terminal bug details
• Original defect filed against Vim