flickering each time a character gets deleted

[astier]

Hello. So far this plugins works great. One thing which bothers me is that the pum flickers each time I press backspace to delete a character. I tested it with the path- and buffer-sources.

This doesn't really happen with deoplete. Maybe its because deoplete sets the completion-delay by default to 0. Setting let g:completion_timer_cycle = 1 helps. If I set it to 0 no completion occurs however.

My questions are:

• Is it possible to make the flickering go away when characters are deleted?
• Could you please allow to set g:completion_timer_cycle to 0 for even faster completion?
• You are saying in the docs that g:completion_timer_cycle should not be lower than 80. However, I had very could results with setting it to 1. Much faster completion. Almost no flickering when I insert characters. Less flickering when I delete characters. Is there a specific reason why it shouldn't be lower than 80?

[haorenW1025]

Popup menu shouldn't be showing in the default config. Did you enable completion_trigger_on_delete? Disabling that will let popup menu disappear when deleting character.

I believe the meaning of completion_timer_cycle has a different concept to deoplete's completion-delay. Because completion-nvim uses timer to control the completion process, the completion_timer_cycle is how often do a timer check the current state of completion? I suggest setting it to 80 because it's quite fast for me, and I'm afraid of shorter timer cycle may results in higher cpu usage (not tested). For even faster completion, the completion should be rework to not using timer to control completion process(like coc and deoplete), I have no plans on doing this for now(and no idea on how to implement this..) but PR is welcome.

[astier]

I did not enable completion_trigger_on_delete. It seems that completion-buffers does not respect this setting. If I try to complete the path it does indeed not show/update the popup menu when deleting characters. Here is my minimal vimrc.

cal plug#begin($XDG_DATA_HOME.'/nvim/plugins')
    Plug 'nvim-lua/completion-nvim'
    Plug 'steelsojka/completion-buffers'
cal plug#end()

au bufenter * lua require'completion'.on_attach()
let g:completion_auto_change_source = 1
let g:completion_trigger_on_delete = 0
let g:completion_chain_complete_list = [
    \{ 'complete_items': ['path'] },
    \{ 'complete_items': ['buffer'] },
\]
se completeopt=menuone,noinsert

Anyway, if say it can't be faster then the deletion-flickering just has to stay. Its not that bad, especially when timer_cycle is set to 1. So far I didn't notice any cpu issues and enjoyed it so far. You can close the issue if there's nothing more to say.

EDIT: The cpu becomes higher. Its not that bad but maybe too high for some people. I figured setting the timer to 10 or 20 is the best mix between responsiveness and cpu for me personally.

[astier]

I also just noticed that the plugin lexima for autoclosing brackets hijacks <bs> and makes completion-nvim trigger completion when hitting <bs> even when g:completion_trigger_on_delete = 0. Thats why when I first tested it also the source path triggered completion on <bs>. I opened an issue for this https://github.com/cohama/lexima.vim/issues/101. There is however still a problem with completion-buffers.

[astier]

I created a new issue for completion-buffers https://github.com/steelsojka/completion-buffers/issues/6

[astier]

Instead of using the timer couldn't the completion just be triggered for each TextChangedI and TextChangedP event? I tried the following but for some reason it isn't doing anything.

au textchangedi,textchangedp * cal completion#trigger_completion()

[astier]

The dev from completion-buffers sais:

I don't think this an issue with the source. The source doesn't trigger when completion is shown. This would be an issue with completion-nvim.

[kkharji]

@haorenW1025 yes this also happens to me when competing a word. sometimes, when I type a letter the list flickers, I have fuzzy option set and perhaps it is related to that.

[kkharji]

#237

[kkharji]

Probably, this issue relates to this #207