2

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
/home/jol/.vim/after/pack/
/home/jol/.vim/after/plugin/
/home/jol/.viminfo
/home/jol/.vim/pack/
/home/jol/.vim/plugin/
/home/jol/.vimrc
/usr/bin/vim
/usr/share/vim
/usr/share/vim/lang/en/LC_MESSAGES/vim.mo
/usr/share/vim/lang/en_US/LC_MESSAGES/vim.mo
/usr/share/vim/lang/en_US.utf8/LC_MESSAGES/vim.mo
/usr/share/vim/lang/en_US.UTF-8/LC_MESSAGES/vim.mo
/usr/share/vim/lang/en.utf8/LC_MESSAGES/vim.mo
/usr/share/vim/lang/en.UTF-8/LC_MESSAGES/vim.mo
/usr/share/vim/pack/
/usr/share/vim/plugin/
/usr/share/vim/runtime
/usr/share/vim/vim81
/usr/share/vim/vimfiles/after/pack/
/usr/share/vim/vimfiles/after/plugin/
/usr/share/vim/vimfiles/pack/
/usr/share/vim/vimfiles/plugin/
vim

/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.
/etc/vimrc
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.

3

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:

oend^\^NOres^\^N

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

oend^[^@Ores^[

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

You could also insert a sleep command (gs).

oend^[gsOres^[

^[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>

or,

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 '18 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 '18 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 '18 at 1:29
  • Nevermind, I get it now. Escape sequences are interpreted in normal mode despite esckeys being off. – JoL Aug 28 '18 at 1:31
  • @JoL, thanks but I don't recommend using ctrl-c in either mode, because a) it is the interrupt command in normal mode, not a no-op and b) in insert mode it does not trigger InsertLeave, breaking any plugin which relies on that. In my opinion, ^\^N is the best alternative way to exit insert mode, so I've added that to the answer. – Mass Mar 5 at 23:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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