You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I love jedi-vim very much, but the performance is a big trouble to me, especially when I press a dot ".", vim get stucked for 3-4 seconds which is very annoyed.
When I switch to emacs with a similar package emacs-jedi, I find it is far more smooth than jedi-vim . I have no idea about the difference. Both of them are using jedi as the backend, and both of them are using a client/server architecture.
After some inspection, I finally figure out there is an obvious difference between jedi-vim and emacs-jedi: The http timeout
What jedi-vim does is:
request the 'jedi-server'
wait the http request until timeout happen (2-4 seconds).
the waiting method here will definitely block the ui, and users can do nothing during 2-4 seconds.
What emacs-jedi does is:
request the 'emacs-jedi-server' and returns immediately, so you can continue editing.
when respones returns and if cursor is still at the same position and no new characters have entered or deleted, popup the completion menu.
when response returns and if cursor has moved or text has been changed, drop the response directly and do nothing.
So there is no 'http timeout' in emacs-jedi, absolutely emacs-jedi got the right way and get more snappy than jedi-vim.
And I suppose is it possible to provide an non-blocking http request mechanism by introducing +timers from vim8/neovim:
post http request to jedi-server and return immediately.
poll the response repeatly in an interval (20Hz eg), this will not block the ui
when response returns in the timer, if cursor is still at the same position and no new characters have been entered or deleted, popup the completion menu.
when response returns and if cursor has moved or text has been changed, drop the response directly and do nothing.
This is exactly what the most completion packages of emacs does.
There are many people are complain about the performance from 2013-2017: #163
If we can introduce this http polling method in jedi-vim, completion can be as smooth as emacs and jedi-vim will make vim great again !!
The text was updated successfully, but these errors were encountered:
There's deoplete and YCM that both allow you to have asynchronous completions. I think that's enough for now. I might be building a client within Jedi, but before that jedi-vim is probably not getting something like this.
I love jedi-vim very much, but the performance is a big trouble to me, especially when I press a dot ".", vim get stucked for 3-4 seconds which is very annoyed.
When I switch to emacs with a similar package emacs-jedi, I find it is far more smooth than
jedi-vim
. I have no idea about the difference. Both of them are using jedi as the backend, and both of them are using a client/server architecture.After some inspection, I finally figure out there is an obvious difference between
jedi-vim
andemacs-jedi
: The http timeoutWhat jedi-vim does is:
the waiting method here will definitely block the ui, and users can do nothing during 2-4 seconds.
What
emacs-jedi
does is:So there is no 'http timeout' in
emacs-jedi
, absolutelyemacs-jedi
got the right way and get more snappy thanjedi-vim
.And I suppose is it possible to provide an non-blocking http request mechanism by introducing +timers from vim8/neovim:
This is exactly what the most completion packages of emacs does.
There are many people are complain about the performance from 2013-2017: #163
If we can introduce this http polling method in
jedi-vim
, completion can be as smooth as emacs andjedi-vim
will make vim great again !!The text was updated successfully, but these errors were encountered: