Deoplete API should never hang #534
Comments
|
I think in deoplete source itself should be marked explicitly as async. More details at the end of #407. |
mqudsi
added a commit
to mqudsi/nvim-config
that referenced
this issue
Oct 30, 2017
While deoplete offers a non-blocking API, there are no non-blocking guarantees and bad providers can still hang on completion collection. See Shougo/deoplete.nvim#534 deoplete-clang is really bad at this and with large C/C++ codebases (such as fish-shell), the editor is slowed down to the point of becoming unusable. deoplete-plugins/deoplete-clang#74 may also apply.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't have a reproducible .vim, and I'm not having any problems with deoplete.
The problem is that while some deoplete sources are fully async, others cause the editor to hang when working on massive projects.
I have omnifunc support completely disabled (not set) in deoplete, but using either clang-deoplete or clang-deoplete2 on a large C++ codebase causes the editor to hang/lag in insert mode.
Suggestion: The deoplete API should never hang, no matter how bad the code in a deoplete completion source is.
The text was updated successfully, but these errors were encountered: