[wish-list] using +timers to speedup completion in vim 8.
skywind3000 opened this issue · 5 comments
People notice that completion in emacs is more smooth than vim.
In spite of client/server architecture in ycm, there is still a http timeout delay which could always get ui stuck.
YCM can get far more snappy by introducing an +timer polling method to deal with the http response:
- post http request to ycmd and return immediately.
- poll the http response repeatly in an interval (20Hz eg), this will not block the ui
- when response returns from ycmd in the timer, if no new characters have been entered or deleted, and cursur is still waiting at the same position, just open the completion popup window directly.
- when response returns from ycmd in the timer, and if the text has been changed, or cursor has moved, simply drop the response or select suggestions which is still available (can still match the changed text).
This is exactly what completion packages in Emacs does, ui delay caused by waiting http timeout could be eliminated and completion in vim can get as snappy as emacs.
And YCM will make vim great again !!
YCM can get far more snappy by introducing an +timer polling method to deal with the http response:
when you say this, does it means that you have a prototype and you experienced that is actually more responsive?
There are a lot of prototype for you, you can try emacs-jedi.
Jedi has serious performance issue, I can feel a noticeable latency when I use jedi with YCM.
Each time when I press a dot ".", the cursor can't be moved for nearly 2-4 seconds in YCM
(I know I can still input new characters during that, but the cursor get stucked on the position of "." during that).
But when I try jedi in emacs, every thing works fine, although jedi is slow, but typing and cursor moving
is very fast. The experience is far more better.
There are a lot of prototype for you, you can try emacs-jedi.
That is not a prototype. The fact that it works in one way in emacs does not mean that it would work the same in vim or that it would get the same benefits. Talking to @puremourning it looks like the last time he profile YCM the thing that could cause visible latency is when on large buffer we have to get the content, and transcode it to utf8. So to be clear, I'm not saying that what you're saying is not true, I'm saying that I don't see the data backing it up, and personally when it comes to performance I don't go and change things if I don't have the data showing about what is really slow and why.
poll the http response repeatly in an interval (20Hz eg), this will not block the ui
It would be much better to use vim 8 jobs, the http client would be a job and access the server using ASIO, as soon as the result is ready it would be passed through a channel and callback your vim script immediately.
This is something I want spooking at for async events in the language server. It is a lot of work and requires very modern Vim.