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

[feature request] Async call signature fetching #761

Open
morphheus opened this issue Dec 1, 2017 · 5 comments
Open

[feature request] Async call signature fetching #761

morphheus opened this issue Dec 1, 2017 · 5 comments
Labels

Comments

@morphheus
Copy link

morphheus commented Dec 1, 2017

My biggest pet peeve with call signatures is the initial delay required for loading the module containing the desired function. This delay is fairly short, ~500ms on average, maybe 1s for Scipy stuff. However, it blocks visual updates, preventing the user from seeing what they type until the call signature can be displayed.

Ideally, the module loading should be done in asynchronously.

This is something I would be willing to implement myself. How much work would be required for such a change? I'm also not sure how this would tie in with the open PR #420 .

@morphheus morphheus changed the title Async call signature fetching [feature request] Async call signature fetching Dec 1, 2017
@davidhalter davidhalter assigned blueyed and unassigned blueyed Dec 1, 2017
@davidhalter
Copy link
Owner

I don't know how easy asynchronous stuff is with Jedi. what do you think @blueyed? It's probably only possible with neovim and VIM 8+? right? I don't think Python's threading would be enough.

@blueyed
Copy link
Collaborator

blueyed commented Dec 3, 2017

Not sure either.

We should maybe consider to hook into the existing vim-echodoc framework?
It only supports the cmdline though, and is maybe not even async itself by now - have not checked.
https://github.com/Shougo/echodoc.vim

@blueyed
Copy link
Collaborator

blueyed commented Jul 28, 2018

I think #652 addresses this.

@blueyed
Copy link
Collaborator

blueyed commented Jul 28, 2018

Just noticed that #420 is also from me, but older - it might be obsolete, or only some parts would be still relevant.

@blueyed
Copy link
Collaborator

blueyed commented Jul 28, 2018

@morphheus
If you are still willing to help here, please try/review #652 first I would say.

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

No branches or pull requests

3 participants