I don't usually have this much trouble debugging issues, but I'm starting to get stumped.

The line doesn't happen when typing the macro out (running it by hand). In fact, it's part of something I recorded.

This doesn't happen when using vim -u NONE, which leads me to believe it's due to something in my configuration. I tried to find the issue by deleting my configuration by sections until I found the one that caused it. However, I've moved and deleted all run-time loaded vim code (I even moved /usr/share/vim/ elsewhere) as well as my ~/.viminfo files and the problem still persists.

I listed all vim related files that vim referred to in system calls:

$ strace -fe trace=file vim +q |& grep -Po '[^"]*vim[^"]*(?=")' | sort | uniq

/etc/vimrc and ~/.vimrc exist, but are empty. ~/.viminfo was generated.

vim -D in these circumstances only results in:

Entering Debug mode.  Type "cont" to continue.
line 2: End of sourced file

Any idea for further debugging is appreciated.

EDIT: Hmm. I found something interesting. Apparently, ofoo^[Obar^[ works perfectly.... ofoo^[Orar^[ fails by making new line "foo2ar". Running :abbrev returns "No abbreviation found".

EDIT 2: Macro ^[Orx^[ deletes 2 letters from the cursor position. I guess it's evaluated like 2x.

EDIT 3: Macro ^[Otx^[ works like 4x, and ofoo^[Otx^[ does indeed print foo4x in a new line.

EDIT 4: Macro ofoo^[Oyx^[ only prints foo, but ofoo^[Oux^[ prints foo5x.

1 Answer 1


When vim encounters ^[Or it interprets it as some kind of special key, for instance a function key. Which specific one vim thinks it is I'm not sure, but for comparison the <f3> key is often ^[OR. These escape codes are interpreted in insert mode as keys to allow using function keys and arrow keys. Ordinarily, it's not an issue because one types more slowly than a macro executes.

One solution is to set noesckeys prior to executing the macro. This option is enabled by vim by default in nocompatible mode. You can choose to re-enable it after or just keep it always off if you never use special keys in insert mode.

An alternative is to use the <c-\><c-n> method of exiting insert mode. So the macro would look like this:


Other control characters could be used, such as ctrl-@, which is a no-op in normal mode:


This will separate the ^[Or into an unambiguous sequence of commands.

You could also insert a sleep command (gs).


^[gs is not usually recognized as an escape sequence. However, this will also cause the macro to sleep for one second. To get around this, we can remap gs to a similar "no operation"

nnoremap gs <nop>


nnoremap <silent> gs :<c-u>sleep 10m<cr>

if you would like a shorter sleep.

  • Thanks, that's it. esckeys (with an "s" at the end, BTW) is set in the normal invocation and unset in vim -u NONE. Who knows what sets it. After a few quick greps into my configuration, /usr/share/vim/ and vim's source, I can't find a plausible place. In any case, it's seems like something I want to keep set. The <nop> idea is great.
    – JoL
    Aug 28, 2018 at 1:09
  • 1
    typo, thanks. and vim sets it by itself when running in nocompatible mode, which is default when you use a vimrc but not default when using vim -u NONE. if you want nocompatible mode you would use e.g. vim -u NONE -N.
    – Mass
    Aug 28, 2018 at 1:27
  • It just occurred to me that it's odd that something like ^[Orx^[ would cause trouble since ^[ is not done while in insert mode. Maybe that's a bug where these escape sequences are interpreted in normal mode, despite the documentation saying otherwise.
    – JoL
    Aug 28, 2018 at 1:29
  • Nevermind, I get it now. Escape sequences are interpreted in normal mode despite esckeys being off.
    – JoL
    Aug 28, 2018 at 1:31
  • 1
    The issue has been fixed by github.com/vim/vim/releases/tag/v8.1.1003.
    – user938271
    Apr 24, 2020 at 17:45

Your Answer

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

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