PUM flickers

[jonathf]

Problem summary

When deoplete PUM/dropdown menu pops up, it starts to flicker about every second or so. Iterating down the list, the selected item "aborts" in the sense that it jumps to the top again. this makes it difficult to select anything except the first item.

The minimal init file under reproduces the problem. Removing deoplete-jedi removes the problem, so I believe the problem is not with deoplete.

Expected

It should not flicker.

Environment Information

• OS:
  Ubuntu 17.04
• Neovim version:

:version
NVIM v0.2.2
Build type: RelWithDebInfo
LuaJIT 2.0.4
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-yDhEcn/neovim-0.2.2=. -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DDISABLE_LOG -Wdate-time -D_FORTIFY_SOURCE=2 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE
=1 -DNVIM_UNIBI_HAS_VAR_FROM -O2 -g -DMIN_LOG_LEVEL=3 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim-yDhEcn/neovim-0.2.2/
build/config -I/build/neovim-yDhEcn/neovim-0.2.2/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/build/neovim-yDhEcn/neovim-0.2.2/build/src/nvim/auto -I/build/neovim-yDhEcn/neovim-0.2.2/build/include
Compiled by pkg-vim-maintainers@lists.alioth.debian.org

Features: +acl +iconv +jemalloc +tui

Provide a minimal init.vim with less than 50 lines (required)

call plug#begin()
Plug 'Shougo/deoplete.nvim'
Plug 'zchee/deoplete-jedi'
call plug#end()

let g:deoplete#enable_at_startup = 1
call deoplete#custom#set('jedi', 'debug_enabled', 1)
call deoplete#enable_logging('DEBUG', '/home/jonathf/deoplete.log')

Generate logfiles if appropriate

1. export NVIM_PYTHON_LOG_FILE=/tmp/nvim-log
2. export NVIM_PYTHON_LOG_LEVEL=DEBUG
3. nvim -u minimal.vimrc

Then look at and attach the files /tmp/nvim-log_{PID} and
/tmp/deoplete.log here.

Steps to reproduce the issue after starting Neovim (required)

Just start typing anything that has known completion.

Upload the logfile(s)

deoplete.log
nvim-log_py3_rplugin.log
nvim-log_py3_script.log

[Shougo]

It is the feature of deoplete and deoplete-jedi.

deoplete supports the asynchronous completion and deoplete-jedi uses the feature.
If the asynchronous completion is enabled, the candidates are updated automatically.

[Shougo]

I think you have used the huge module.
I don't have the problem when Python editing.

[jonathf]

To clarify from my end: I am currently not able to use the PUM with deoplete-jedi. If I press <down> it will select the first item for about a fraction of a second before "cancelling". If I am really fast, I may get to press <up><cr> to maybe reach the last item in the PUM before it resets. If I am unlucky, the PUM resets, and it expands first item in the list.

Are you saying this is expected behavior, and to not interact with the PUM using deoplete except for accepting first item? Because that would be weird considering that you have an animation on the deoplete readme that demonstrate PUM iteraction.

Do you mind clarifying what you mean by "the huge module"? Is this something I could change on my end?

[jonathf]

So I checked the difference between a simple small file and a larger project, and there behavior is not reproducible in smaller projects. Perhaps that is what you meant with "the huge module".

Is there anyway to mitigate this? Obviously I can not stop working on larger code bases.

[Shougo]

So I checked the difference between a simple small file and a larger project, and there behavior is not reproducible in smaller projects. Perhaps that is what you meant with "the huge module".

Yes.

Please upload the huge examples.
I will test the behavior.

I think it is hard to fix.
Because it is intended async behavior.

[Shougo]

To clarify from my end: I am currently not able to use the PUM with deoplete-jedi. If I press it will select the first item for about a fraction of a second before "cancelling". If I am really fast, I may get to press to maybe reach the last item in the PUM before it resets. If I am unlucky, the PUM resets, and it expands first item in the list.

You must wait the input if you want to select the completion.
I think other completion plugin has the same problem.
Vim/neovim has not support asynchronous popup menu update.
To update the popup menu, deoplete must close the window and reopen it.
So the selection will be reset.

[Shougo]

You can change g:deoplete#auto_refresh_delay.

[Shougo]

I may fix the problem in pararell branch.

Shougo/deoplete.nvim#602

[jonathf]

Unfortunately, the code that causes the problem is propitiatory, so I am not able to share. I will need to narrow down the problem to see if there is a specific module that causes it, or if it is the accumulation. I will post the code here if I can reduce the problem to something I can publish.

The g:deoplete#auto_refresh_delay option works as expected giving me a little better time. But it by no means optimal as I need to time browsing between the "ticks".

I will take a look at your parallel branch and see if it help.

[Shougo]

Unfortunately, the code that causes the problem is propitiatory, so I am not able to share. I will need to narrow down the problem to see if there is a specific module that causes it, or if it is the accumulation. I will post the code here if I can reduce the problem to something I can publish.

You can upload other open source modules instead.

I will take a look at your parallel branch and see if it help.

The implementation is imcomplete.
It needs more time to test.

[jonathf]

I've been able to replacate the problem when using the repo numpy/numpy, branch master.

• From repo root, open the file nvim numpy/linalg/linalg.py -u path/to/init.vim
• Go to line 70: 70G
• Open a line bellow: o
• Insert _as<down>
  The selection of the PUM should cancel right away.

In the case of numpy the effect is only temporary. Letting it lingers for about 6-7 seconds, and the problem disappears for some reason. I would like to note that this is not the case in my private repo.

[Shougo]

OK. I will test it later.

[Shougo]

In the case of numpy the effect is only temporary. Letting it lingers for about 6-7 seconds, and the problem disappears for some reason. I would like to note that this is not the case in my private repo.

Because, deoplete-jedi finished the completion.
It is the updating problem until the finish.

[Shougo]

I have implemented the feature.
You can test it in Shougo/deoplete.nvim#602.

[jonathf]

I've tried switching to the parallel branch (git checkout parallel; git pull) while using the minimal init described above. I get the following error on start up:

Error detected while processing function deoplete#enable_logging:
line    2:
E119: Not enough arguments for function: deoplete#util#rpcnotify
Press ENTER or type command to continue 

Using a non-minimal init file, I catch the following message:

error caught in async handler '/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete:function:_deoplete_init [[]]'
Traceback (most recent call last):                                                                                               
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/__init__.py", line 28, in init_channel
    self._deoplete = Deoplete(self._vim)                                                                           
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/deoplete.py", line 41, in __init__
    self.on_event(context)                                                                                     
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/deoplete.py", line 197, in on_event
    self.check_recache(context)                                                                                 
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/deoplete.py", line 187, in check_recache
    self.load_filters(context)                                                                                       
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/deoplete.py", line 172, in load_filters
    parent.add_filter(path)                                                                                         
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/parent.py", line 32, in add_filter
    self._put('add_filter', [path])                                                                            
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/parent.py", line 85, in _put
    self._proc.write({'name': name, 'args': args, 'queue_id': queue_id})                                 
  File "/home/jonathf/cfg/vim/plugged/deoplete.nvim/rplugin/python3/deoplete/process.py", line 74, in write
    self._proc.stdin.flush()                                                                               
BrokenPipeError: [Errno 32] Broken pipe
Press ENTER or type command to continue

In either case, completion does not work.

[Shougo]

Please use the latest version instead.
I have updated it.

[jonathf]

I pulled the newest version of parallel. I am now getting the Broken pipe error above, but now both for minimal and full vim init.

[Shougo]

I cannot reproduce the error.
Fortunately, you are Python developer.
Please debug the problem...

The child process seems crashed.

[jonathf]

I am tinkering with it now. Looks like I just needed to update deoplete-jedi as well and the crashes stopped. I'll leave it be with that.

However the "flicker" problem still persists. And by the looks of it, the rate is up to about 14 times a second:
deoplete.log
In other words, it is no longer flickering. Instead the PUM is just "disabled" as I can not iterate it.

[Shougo]

I am tinkering with it now. Looks like I just needed to update deoplete-jedi as well and the crashes stopped. I'll leave it be with that.

Hm. OK.

[Shougo]

However the "flicker" problem still persists. And by the looks of it, the rate is up to about 14 times a second:

:help g:deoplete#auto_refresh_delay

In other words, it is no longer flickering. Instead the PUM is just "disabled" as I can not iterate it.

Really? I cannot reproduce the problem.
Fortunately, you are Python developer.
You can find the reason.

[Shougo]

I think the completion is very slow.

Shougo/deoplete.nvim#471

The feature is implemented.

[jonathf]

Ah, that did it! By setting delay to above 100, the flickers disappear.

Thank you for your patient diagnosing this problem. It is much appreciated.
Also thank you for making deoplete. Your contribution to the vim community is awesome.

[Shougo]

Ah, that did it! By setting delay to above 100, the flickers disappear.

I may change the default value.

[Shougo]

Also thank you for making deoplete. Your contribution to the vim community is awesome.

The text editor is my life.

[Shougo]

I have reproduced probem in master.
It should be fixed in deoplete.

[Shougo]

It is bug of deoplete.
Closing.