4

I am using terminal vim 7.4 and standard completion, i.e.

  • <C-x>,<C-p> for word completion
  • <C-x><C-o> omnicompletion
  • <C-x>,<C-f> for file completion etc,

~/.vimrc completion config

filetype plugin on
set omnifunc=syntaxcomplete#Complete
set completeopt=longest,menuone,preview
set iskeyword+=-
set dictionary=/usr/share/dict/words
set infercase

So say I'm writing some PHP and I

  • type var_d (beginning of var_dump())
  • then use omnicompletion Ctrl - x,Ctrl - o
    Vim is quick at summoning the completion list and incrementally narrowing the results.
  • Then I navigate up the completion menu to var_dump and select with <C-y>

At this point vim has a delay of about 1 to 1.5 seconds before inserting the text into the line itself.
Its not a "visual" delay either, if I type anything during the delay period vim discards the completion selection - and I need to start the completion again.
The delay seems strange and unnecessary because all the hard work of searching and sorting results has been done at this point, all vim needs to do is just put the item into the line.
Is it possible to "fix" this delay so vim just instantly puts the selection in the line?

2
  • 2
    Sounds like you have a mapping that starts with <c-y> somewhere. I suspect the delay is Vim timing out waiting for the rest of the mapping. Have you tried disabling plugins and settings that you don't need as a minimal working example? See meta.vi.stackexchange.com/questions/98/… for hints on debugging.
    – John O'M.
    Feb 27, 2016 at 16:02
  • @JohnO'M. thanks this looks promising. I have tried a core install of vim with only a handful of basic plugins, and the lag has actually gone away! so as you say, I will now try to systematically add the plugins back in to discover the plugin that that is causing the issue. Feb 27, 2016 at 23:53

1 Answer 1

4

Thanks to @John O'M for putting me on the right path.

The cause of the lag was a plugin I'm using: emmet-vim which provides expansion of special abbreviations into full HTML elements, it creates lots of bindings to <C-y>

i.e.

:map <C-y>

v  <C-Y>c        <Plug>(emmet-code-pretty)
v  <C-Y>m        <Plug>(emmet-merge-lines)
n  <C-Y>A        <Plug>(emmet-anchorize-summary)
n  <C-Y>a        <Plug>(emmet-anchorize-url)
n  <C-Y>k        <Plug>(emmet-remove-tag)
n  <C-Y>j        <Plug>(emmet-split-join-tag)
n  <C-Y>/        <Plug>(emmet-toggle-comment)
n  <C-Y>i        <Plug>(emmet-image-size)
n  <C-Y>N        <Plug>(emmet-move-prev)
n  <C-Y>n        <Plug>(emmet-move-next)
v  <C-Y>D        <Plug>(emmet-balance-tag-outword)
n  <C-Y>D        <Plug>(emmet-balance-tag-outword)
v  <C-Y>d        <Plug>(emmet-balance-tag-inward)
n  <C-Y>d        <Plug>(emmet-balance-tag-inward)
n  <C-Y>u        <Plug>(emmet-update-tag)
n  <C-Y>;        <Plug>(emmet-expand-word)
v  <C-Y>,        <Plug>(emmet-expand-abbr)
n  <C-Y>,        <Plug>(emmet-expand-abbr)

I'm sure remapping it would solve the problem also, but without the plugin the lag goes away.

2
  • Looks like the plugin supports changing <c-y> to something else like so: let g:user_emmet_leader_key='<C-Z>' in your vimrc. Would be a good way to keep the plugin simply while avoiding the lag.
    – John O'M.
    Feb 28, 2016 at 21:48
  • @JohnO'M. nice find. Im just so happy to get rid of that lag, That lag and another lag switching to normal mode were the cause of many errors and frustration - which were making me question modal editing in general - with delay fixed - error rate is far lower and types of errors are less destructive too Feb 28, 2016 at 21:52

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.