As a concrete (although hyperbolic) example:

nnoremap , a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>a<esc>aX<esc>

This mapping will take a bit to actually type out an "X" (at least in my underpowered Celeron. You may have to up the number of a<esc> if you have a better CPU).

I have dozens of plugins installed, some that can make a huge amount of operations running possibly hundreds of lines of code, but all of them execute in a fraction of the time, so I was a bit surprised to find out that, out of all of these operations, changing modes is what made neovim chug.

Am I missing something? Is there a way to speed up this type of mapping?

  • 1
    Do you have any autocommands on InsertEnter or InsertLeave? That seems a likely culprit. Use :verbose to see where they come from
    – D. Ben Knoble
    Commented Aug 18, 2021 at 10:46
  • @D.BenKnoble You're right. The mapping ran with no lag after I removed an autocommand with InsertLeave. Thanks a lot! I've submitted an edit to add your tip to the current answer. Commented Aug 18, 2021 at 16:31
  • @D.BenKnoble Update: The edit was rejected by the author, so feel free to leave this tip as an answer, as it is the correct one. Commented Aug 18, 2021 at 16:37
  • An edit doesn’t make sense here, so I understand the rejection. I can write an answer later, or you can write one now if you like—you know the offending command better than I.
    – D. Ben Knoble
    Commented Aug 18, 2021 at 16:59

2 Answers 2


It would help if you would give a more concrete example of what you need to do that takes a long time. For me your example is instantaneous, even if I make it several times as long.

However, to answer your question, it might help to use <c-o> in insert mode to run one normal mode command and then Vim automatically switches back to insert mode.

You can also read registers into your cursor position without switching out of insert mode using <c-r> and then the register name. You can even read in an expression this way using the = register. For example:

nmap , atest<c-r>=1*2*3*4<cr>test<c-o>otest

Another thing you can do is set the 'lazyredraw' option, which prevents Vim from redrawing the screen while running macros. Although it doesn't seem to make any difference for me with your example.

  • Indeed, I was not able to reproduce it as well when restarting vim, so maybe it was a fluke. I was able to reproduce it with the o command though. Is the mapping nnoremap , o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc>o<esc> laggy on your machine as well? If not, it may be something peculiar to mine. Commented Aug 18, 2021 at 2:11
  • No, not laggy. Did 'lazyredraw' help at all?
    – Heptite
    Commented Aug 18, 2021 at 4:44
  • Yes, it did! Both yours and D. Ben's tips were required to remove the lag. I've submitted an edit to add his tip to your answer. Commented Aug 18, 2021 at 16:25
  • And as a side note: I still get lag on ...o<esc>o<esc>o<esc>.... However, I also get the exact same amount of lag when typing only 80o<esc>, so the o operation is probably the culprit there, not the mode swapping. So, after the edit, I'll consider the question answered. Commented Aug 18, 2021 at 16:28
  • Your edit should probably be a separate answer.
    – Heptite
    Commented Aug 18, 2021 at 16:30

Credits to D. Ben Knoble and Heptite for the performance tips.

The biggest culprit ended up being InsertEnter and InsertLeave autocommands. By tracking them down and removing them, there was a significant performance improvement.

The remaining bit of lag was solved by "set lazyredraw", which stops vim from redrawing the screen while running macros.

Note: There's still a lesser (but noticeable) delay if I run the mapping a higher amount of times, say 100 (with qa,q100@a), although this is very much acceptable. Nonetheless, any tips to further improve performance are appreciated.

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.