-
-
Notifications
You must be signed in to change notification settings - Fork 369
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
Always handle "completion/resolve" requests #4463
base: master
Are you sure you want to change the base?
Conversation
Resolves the LSP "completion/resolve" requests, even if there is nothing more to resolve. If there is nothing to resolve, we simply return the initial completion item. If we reject "completion/resolve" requests, then some LSP clients show our rejection as pop-ups which are hugely distracting. We change completion tests to always resolve completions, regardless of the existence of `_data_`, as this seems to be the behaviour of VSCode.
Hmmm. So what's happening? We advertise support for resolve but don't actually resolve it? Or we advertise resolve because some plugins support resolve, but not all of them do? And so when we hit that case we get a rejection? |
We advertise "completion/resolve", and the completion plugin supports it, but for some completion items, there is simply no more info to resolve. But vscode still asks for "completion/resolve" which so far, we simply rejected if it was for a completion that didn't have any more info. E.g., documentation for local variables, such as in |
Okay, I guess I'm worried that we have the same problem in other plugins for other reasons, but I guess we can tackle that later! |
We do, not with resolve in particular, but in other instances, e.g. semantic-token plugin rejects requests by default as well, since the plugin is disabled. Cabal plugin also rejects certain requests, such as I will open an issue tracking this in general. |
Add explanations and justification for 'NothingToResolve' constructor. Also, include historical note to explain how we end up with this 'CompletionResolveData' version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Emmm, so we might need to respond with a dummy respond to these request as well ? |
Yeah, that sounds like a reasonable solution. Maybe not so pretty, but solves the issue as well. |
We might be better off solving this issue by adding logic to the completion/resolve dispatch logic. For example, we could specify that by convention if the resolve request doesn't have any Then the request wouldn't fail, and it would be handled at a central location. |
Resolves the LSP "completion/resolve" requests, even if there is nothing more to resolve.
If there is nothing to resolve, we simply return the initial completion item.
If we reject "completion/resolve" requests, then some LSP clients show our rejection as pop-ups which are hugely distracting.
We change completion tests to always resolve completions, regardless of the existence of
_data_
, as this seems to be the behaviour of VSCode.Closes #4451