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

apparently fix completions not appearing immediately (fixes #17) #20

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tom95
Copy link

@tom95 tom95 commented Oct 15, 2017

this huge fix appears to make completions show up immediately again. as far as suspicion goes, it appears to be a conflict caused by deoplete invoking the plugin as soon as anything is typed (min_patter_length==0) and the gather_candidates refusing to find anything until there's at least two characters

I might be mistaken about the intent of this, in particular since the problem seems to only have started recently or only affects very few people, but it fixed it on my system.

this huge fix appears to make completions show up immediately again. as far as suspicion goes, it appears to be a conflict caused by deoplete invoking the plugin as soon as anything is typed (min_patter_length==0) and the gather_candidates refusing to find anything until there's at least two characters
@wzrdtales
Copy link

@tom95 This does neither fix nor solve the problem. Actually this breaks the handling of i.e. structs, vim wont really resolve them anymore afterwards. And what I also noticed is that, since some of the "latest" updates of deoplete it seems like this whole module operators far less good than before. Before it resolved functions from a different header just fine. Now it does not anymore, only when I type it out myself as a function and press backspace after that it will resolv the clang completion correctly. I assume something in deoplete just lately changed which altered the behavior hugely.

@tom95
Copy link
Author

tom95 commented Dec 28, 2017

When I created this patch it solved all problems I encountered. Trying it right now with the newest deoplete, I only receive a lot of errors, both with and without my patch, so I'd guess some API change in deoplete is causing trouble.

@wzrdtales
Copy link

probably, would also be my guess, before I've updated today, everything worked even without your patch though. So it is probably entirely due to the API. Unfortunately i don't know which version I used before :/

@wzrdtales
Copy link

@tweekmonster Do you have something in work concerning this topic?

@Shougo
Copy link
Contributor

Shougo commented Feb 8, 2018

Reprodocued.

It should be removed.

I don't know the implementation though.

You can configure it manually.

call deoplete#custom#source('clang2', 'min_pattern_length', 2)

@tweekmonster Ping.

@wsdjeg
Copy link
Collaborator

wsdjeg commented Feb 8, 2018

@Shougo I will test it in SpaceVim,and will fix it.

@tweekmonster
Copy link
Owner

@Shougo I was trying to take a look, but I can't seem to get logging to work.

@tweekmonster
Copy link
Owner

Also, the reason for having the min length set to 0 was because it relied on the auto_complete_delay to get the "min length" from human behavior instead of an arbitrary fixed minimum. That way typing whatever-> and pausing would actually give you results instead of needing to type two more characters. Don't know about you, but I often don't know what I'm looking for and rely on completions to peek into struct membership.

It looks like the default delay was lowered from 150 to 50. Try raising it to 150. In my experience, 250ms is where it starts to annoyingly noticeable.

50ms is pretty low considering that in most fast apps, there's a ~20ms round trip from hardware key press to software key processing. In terminal nvim, the delay could be greater since there's a Terminal emulator that processes the keystrokes before forwarding it to nvim, even more so if tmux and/or ssh is involved. nvim GUIs could have noticeable delays as well since nvim is controlled via RPC.

In any case, these completions could benefit from maintaining a stale cache to get completions out faster (sort of like deoplete-jedi's stale cache).

@Shougo
Copy link
Contributor

Shougo commented Feb 8, 2018

@Shougo I was trying to take a look, but I can't seem to get logging to work.

It is deoplete's bug. It is already fixed in master.

@Shougo
Copy link
Contributor

Shougo commented Feb 8, 2018

because it relied on the auto_complete_delay to get the "min length" from human behavior instead of an arbitrary fixed minimum.

Why does not use input_pattern feature?

@tweekmonster
Copy link
Owner

Why does not use input_pattern feature?

It was deferred to get_complete_position() because pattern has to be slightly different for ObjC and C++. I can't remember the exact reason I had, but it was easier to handle that way.

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

Successfully merging this pull request may close these issues.

None yet

5 participants