Feature/completion item/resolve #25
Conversation
|
@krassowski, any updates on this one? |
|
No, sorry not yet. Feel free to pick it up if you need it. Otherwise, I will get to finish it eventually, but through May I am having busy time at Uni and cannot afford to do both maintenance and active development. |
|
@krassowski, no worries! I was just checking in to see what was the state of this PR! Have a nice end of semester |
krassowski
force-pushed
the
krassowski-feature/completionItem/resolve
branch
from
c88c554 to
24911a8
Compare
|
Sorry it took me so long to get back to this. I tried to use the proposed document-specific caching mechanism but I don't think it is possible as explained in #25 (comment). |
|
Hi @krassowski, no worries! I've just left you a suggestion on the review discussion. |
The document identifier is stored in the completion item data.
krassowski
force-pushed
the
krassowski-feature/completionItem/resolve
branch
from
5b82377 to
79fc79f
Compare
| @@ -49,6 +49,11 @@ | |||
| "default": false, | |||
| "description": "Enable fuzzy when requesting autocomplete." | |||
| }, | |||
| "pylsp.plugins.jedi_completion.eager": { | |||
There was a problem hiding this comment.
I don't know how we should manage these kind of configuration options that apply to both jedi, rope and possibly other completion backends
There was a problem hiding this comment.
I think splitting them by plugin is fine because some plugins may be very fast to eagerly resolve completions and some may be slow. It might be beneficial to let user/IDE make this choice (not necessarily today with rope and jedi as only completion providers, but potentially in the future).
This made me realise I missed adding the setting to schema for rope...
| @@ -162,8 +162,8 @@ def capabilities(self): | |||
| 'resolveProvider': False, # We may need to make this configurable | |||
| }, | |||
| 'completionProvider': { | |||
| 'resolveProvider': False, # We know everything ahead of time | |||
| 'triggerCharacters': ['.'] | |||
| 'resolveProvider': True, # We could know everything ahead of time, but this takes time to transfer | |||
There was a problem hiding this comment.
If this value is True, then it means that eager is False, right? Then if a client decides to have all the information ready and sets eager to True, then it is their responsibility to not calling completionResolve?
There was a problem hiding this comment.
If this value is True, then it means that eager is False, right?
IMO no, eager still can be True. resolveProvider just declares that server will handle completionItem/resolve requests; it does not forbid server to return resolved items in the first place.
if a client decides to have all the information ready and sets
eagerto True, then it is their responsibility to not callingcompletionResolve?
No, the client is still allowed to call completionItem/resolve, it will be just inefficient for them to do so.
|
Hi @krassowski, thanks for your work on this one, I appreciate a lot that you managed to remove that global variable mechanism! I left you a few questions about the behaviour of this new feature. |
|
Thanks for this work @krassowski! |
Supersedes palantir/python-language-server#905. Rebase of #1.
eageroption to rope_completion and jedi_completion allow users using clients which cannot yet handlecompletionItem/resolveto restore to eager resolution (inside oftextDocument/completions)TODO: