vim-easymotion
vim-easymotion copied to clipboard
easymotion
`easymotion-linebackward` is slower than its `forward` counterpart
.vimrc
map <Leader>l <Plug>(easymotion-lineforward)
map <Leader>h <Plug>(easymotion-linebackward)
Searching forward is pretty much instantaneous, while searching backwards yields good 2s. delay. Any idea why?
The culprit of this bizarre bug for me was gitgutter. Switching to Signify fixed it.
I blamed gitgutter too early. The reason this happens is because gitgutter by default has bindings like <leader>h${KEY}, where ${KEY} can be something like u for "unstage this hunk". When you press <leader>h, vim has to wait to make sure you don't actually want to press one of gitgutter's shortcuts (this wait time is tweakable with :set timeoutlen=100, which sets the timeout len to 100ms instead of the default 1000ms).
As a very easy test, you could change your binding to:
map <Leader>H <Plug>(easymotion-linebackward)
Assuming you don't have any bindings that start with <leader>H, that should be pretty fast. From there you have a few options. You can:
- Change your EasyMotion bindings.
- Reduce
timeoutlen(this might make using vim harder). - Disable gitgutter's hunk bindings and optionally rebind them to something else. You can do
let g:gitgutter_map_keys = 0to disable all of gitgutter's bindings (careful, this can disable other gitgutter bindings you use), or disable the hunk bindings individually. - Switch to Signify (which comes without default hunk bindings) and optionally come up with your own hunk bindings.
Much vim performance troubleshooting can be done by plugin bisecting (turning half off at a time to see if your problem goes away).
Sorry for the wall of text. HTH.
@xbe , no need to be sorry, I am grateful for your research.
I am not using (neo)vim as much as I used to and have reduced number of plugins down to 2:
- Nerdcommenter
- matchquote
That being said, there are plenty of people who use Easymotion+GitGutter combo.
Now, when they search the web your post will save them time.