Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flickering with deoplete #71

Open
rgrinberg opened this issue Feb 27, 2016 · 3 comments
Open

Flickering with deoplete #71

rgrinberg opened this issue Feb 27, 2016 · 3 comments

Comments

@rgrinberg
Copy link

When used in conjunction with deoplete I get constant cursor flickering. This flickering disables when I disable tmux-complete so I'm pretty certain this plugin is the cause of it. I'm wondering why tmux-complete causes this however, is it because gathering candidates is slow?

@wellle
Copy link
Owner

wellle commented Mar 11, 2016

@rgrinberg: Thanks for opening this issue, I've had noticed similar problems myself before.

Usually it is related to gathering candidates, especially if you have many tmux sessions and windows open, it can take a noticeable time to process all visible words. There are already some settings

g:tmuxcomplete#capture_args
g:tmuxcomplete#list_args

which can be used to control which sessions, windows and what scrollback to consider. I think most of these issues could be resolved by limiting the search space used for live autocompletion. For on demand completion a slightly longer delay is usually acceptable, that's why this wasn't always a priority.

Unfortunately these settings are currently not documented and I take this issue as motivation to do that. I'm planning to include some best practices to help with issues like the one you're seeing.

Unfortunately I can't promise that I'll come to this soon, but I'll definitely put it on my list 👍

Side note: Maybe it's even possible to do all that processing in the background with Neovim, but I'm not too familiar how that would be done. If anyone would have some pointers that might give me a head start.

@justinmk
Copy link
Contributor

This may have been alleviated by Shougo/deoplete.nvim@2f6f7b9

@rgrinberg Can you confirm/deny?

@blueyed
Copy link
Contributor

blueyed commented Apr 27, 2016

I am using g:deoplete#auto_complete_delay = 50 (or 100), but it's still noticable.

Profiling shows this:

FUNCTION  tmuxcomplete#completions()
Called 12 times
Total time:   1.172690
 Self time:   1.172442
count  total (s)   self (s)
   12              0.000068     let pattern   = '^' . escape(a:base, '*^$][.\') . '.'
   12              0.000051     let list_args = get(g:, 'tmuxcomplete#list_args', '-a')
   12   0.000341   0.000093     let grep_args = tmuxcomplete#grepargs(a:base)

   12              0.000075     let command  =  'sh ' . shellescape(s:script)
   12              0.000048     let command .= ' -p ' . shellescape(pattern)
   12              0.000045     let command .= ' -s ' . shellescape(a:splitmode)
   12              0.000038     let command .= ' -l ' . shellescape(list_args)
   12              0.000043     let command .= ' -c ' . shellescape(a:capture_args)
   12              0.000041     let command .= ' -g ' . shellescape(grep_args)

   12              0.000029     if $TMUX_PANE !=# ""     " if running inside tmux
   12              0.000040         let command .= ' -e' " exclude current pane
   12              0.000010     endif

   12              1.163400     let completions = system(command)
   12              0.000178     if v:shell_error != 0
                                    return []
                                endif

   12              0.008093     return split(completions, '\n')

I could imagine that it would be better already when
rplugin/python3/deoplete/sources/tmuxcomplete.py would not call the Vim
function, but do the job itself.

And then it's also a matter of configuration probably: I would like to use the tmux completion on demand only, and not on-the-fly all the time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants