When I use mapped key sequences which cause an immediate change in the file (e.g. cw, dw, D, C), i have a wait time of roughly 1 second. Other mappings which are just movement (e.g. 3w) or movement and a mode change (e.g. A or I) do not cause any delay.

Currently my attempted solutions include:

  • Changed ttimeout and timeout (neither was set to have a timeout, I tried messing with them anyway)
  • used :profile file * and :profile func * - did not see anything which ran more than once or had a runtime over roughly ~0.1 seconds (my experiment was to open a file and type a bit - experienced the delay several times while profiling)
  • To make sure it wasn't my terminal (iTerm2) waiting for something, I loaded up vanilla vi (no plugins or anything) and tried that - no delays there.

I'm on neovim v0.4.4, in iTerm2. Any help or other avenues to explore are appreciated. Is there any way to use :profile for mapped key sequences?

Edit: as per filbranden's feedback I loaded nvim using nvim --clean, and the problem isn't there. Tomorrow I will try removing different plugins and see what causes the problem, then report back.

Edit 2: As per eyal karni's advice I checked nmap cw, which reported no mapping found. I also don't see anything that looks relevant in au, but to be honest, I'm new enough to neovim that I could be missing something - I searched it for cw and didn't find anything.

  • 2
    Welcome to Vi and Vim! Can you check if the problem still happens if you have no plug-ins or settings from init.vim loaded? You can start NeoVim that way with nvim --clean. Please edit the question to report whether that helps or not.
    – filbranden
    Sep 27, 2020 at 21:28
  • 2
    I assume you have an overlapping mapping. It waits to see if it completes the mapping. Try nmap cw. Or just nmap and verify ok. Also, check au
    – eyal karni
    Sep 28, 2020 at 1:09
  • 2
    See How do I debug my vimrc file? for a recommendation on how to narrow down to the setting or plug-in that is causing the issue...
    – filbranden
    Sep 28, 2020 at 2:24
  • 1
    @filbranden it turns out that the offending line was the following: ` set clipboard=unnamed,unnamedplus` and the lag was caused by clipboard interaction - pasting is slow with it on too. Any idea why this might have studdenly started, or should I just ask that separately? I've had this in my vimrc for over a year.
    – Exnur
    Sep 29, 2020 at 22:10
  • 1
    Awesome, will do - thanks for helping me navigate both vim and stackexchange.
    – Exnur
    Sep 29, 2020 at 22:32

1 Answer 1


Turns out the issue was not with immediate changes as I thought, but with clipboard interaction. I bisected my vimrc repeatedly until I found the offending line, which was:

set clipboard=unnamed,unnamedplus

This was making vim use the system clipboard. It's annoying (imo) to not have vim use the system keyboard, so for now, I have replaced this by making the following mappings (which only work on mac os, thus the if statement):

if has('macunix')
  " pbcopy for OSX copy/paste
  vmap <C-x> :!pbcopy<CR>
  vmap <C-c> :w !pbcopy<CR><CR>
  noremap <C-p> :read !pbpaste<CR>

The root of the issue appears to be slowness in the actual pbcopy and pbpaste tools, which are what nvim was using when I had the clipboard variable set. The delay persists on the terminal without nvim:

ethan ~
06:56:57 PM > time echo "abcde" | pbcopy
Executed in  333.49 millis    fish           external
   usr time  292.80 millis  140.00 micros  292.66 millis
   sys time   34.45 millis  660.00 micros   33.79 millis

Some additonal system information:

nvim --version output:

NVIM v0.4.4
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/tmp/neovim-20200808-17465-1c37yvx/neovim-0.4.4/build/config -I/tmp/neovim-20200808-17465-1c37yvx/neovim-0.4.4/src -I/usr/local/include -I/tmp/neovim-20200808-17465-1c37yvx/neovim-0.4.4/deps-build/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include -I/usr/local/opt/gettext/include -I/tmp/neovim-20200808-17465-1c37yvx/neovim-0.4.4/build/src/nvim/auto -I/tmp/neovim-20200808-17465-1c37yvx/neovim-0.4.4/build/include
Compiled by brew@Mojave

OS: macOS Mojave 10.14.6

  • 1
    You might want to take a look at this: neovim.io/doc/user/provider.html#clipboard
    – filbranden
    Sep 29, 2020 at 22:41
  • 1
    Though essentially what that is saying is that NeoVim should be automatically using pbcopy and pbpaste if you use the "* and "+ registers... In other words, you don't need the special mappings for that, if you use the registers. Also... Do you see a slowdown if you use the mappings? If so, there might be a problem with those tools themselves...
    – filbranden
    Sep 29, 2020 at 22:43
  • 1
    Yeah, i saw that - I believe you're right about there being problems with the tools themselves, they are indeed slow on the terminal just by themselves: 06:34:41 PM > time echo "abcde" | pbcopy Executed in 336.73 millis (cleaned up the output a bit - formatting wasn't going well). This is about the same delay that i see in vim, maybe a little faster on the terminal.
    – Exnur
    Sep 29, 2020 at 22:47
  • 1
    There's also Ask Different where they might know more about Mac stuff...
    – filbranden
    Sep 29, 2020 at 22:59
  • 1
    All i can add is I don’t notice any sluggishness with either the pb tools or the star register in vim on either of my older macs (2012/2015)
    – D. Ben Knoble
    Sep 30, 2020 at 12:18

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.