-
Notifications
You must be signed in to change notification settings - Fork 770
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
Support implementing quickfixes via language server #219
Comments
I am also trying to thread this particular needle, and have come to the conclusion that it is something to do with I look forward to a comprehensive explanation. |
Hmm... yeah |
Quick fixes are currently |
Okay... I think the pieces of this puzzle finally are starting to click together in my head. To indicate which commands to execute on the server I think we need to use I think that was the only piece of this puzzle that was still missing. I'll try this out tomorrow and see if I can make that work. |
Hmmm... vscode sends a rather sparse looking 'capabilties' object upon initialization. {
"jsonrpc": "2.0",
"id": 0,
"method": "initialize",
"params": {
"processId": 1698,
"rootPath": "/home/kdvolder/git/sts4\/concourse",
"capabilities": {},
"trace": "off"
}
} So I guess it doesn't provide support for this stuff yet. Which also means that I won't be able to keep good on my promise to try this out tomorrow and report back. Or would that support be available already on the 'insiders build'? Currently I'm just using the latest stable vscode release. |
Never mind I am dumb. I needed to update the language-server-client module version in my package.json to get protocol version 3.0 support. |
And does vscode then actually use the new features if you do that? Are you running a dev version of vscode? |
Ok, I get it now. The |
@alanz I'm still trying to figure out exactly what versions I need for everything to work together. I just updated the client version but I'm getting some compile errors, which I gather is because it needs a more up-to-date vscode api to compile against. I'll post an update if I figure it all out. Right now I can't really answer your questions yet as until this compiles I can't really see it run and debug things. |
FYI, I updated my extension Using the standard vscode, current version, installed from a deb. |
And this is the {"jsonrpc":"2.0"
,"id":0
,"method":"initialize"
,"params":
{"processId":5196
,"rootPath":"/home/alanz/tmp/haskell-hie-test-project"
,"rootUri":"file:///home/alanz/tmp/haskell-hie-test-project"
,"capabilities":
{"workspace":
{"applyEdit":true
,"workspaceEdit":{"documentChanges":true}
,"didChangeConfiguration":{"dynamicRegistration":false}
,"didChangeWatchedFiles":{"dynamicRegistration":false}
,"symbol":{"dynamicRegistration":true}
,"executeCommand":{"dynamicRegistration":true}
}
,"textDocument":
{"synchronization":
{"dynamicRegistration":true
,"willSave":true
,"willSaveWaitUntil":true
,"didSave":true}
,"completion":
{"dynamicRegistration":true
,"completionItem":{"snippetSupport":true}}
,"hover":{"dynamicRegistration":true}
,"signatureHelp":{"dynamicRegistration":true}
,"references":{"dynamicRegistration":true}
,"documentHighlight":{"dynamicRegistration":true}
,"documentSymbol":{"dynamicRegistration":true}
,"formatting":{"dynamicRegistration":true}
,"rangeFormatting":{"dynamicRegistration":true}
,"onTypeFormatting":{"dynamicRegistration":true}
,"definition":{"dynamicRegistration":true}
,"codeAction":{"dynamicRegistration":true}
,"codeLens":{"dynamicRegistration":true}
,"documentLink":{"dynamicRegistration":true}
,"rename":{"dynamicRegistration":true}
}
}
,"trace":"off"}
} |
So I made some progress. But hit a little snag. When I try to register the my quickfix commands via the protocol I'm getting an error like this:
Not really 100% sure of this, but poking around a bit with the debugger, I find that there is no handler for Is the reference implementation actually using a different name than the Spec? |
Indeed that seems the case, after switching over to using microsoft/vscode-languageserver-node#199 I think its clear now that the LSP protocol has everything it needs to handle quickfixes properly. So I'm closing this ticket. |
@kdvolder Can you give me an example of the registration message you send that works? |
nevermind, I got it going too, by making sure my extension code is up to date. See https://github.com/alanz/vscode-hie-server/tree/168ad64931af4ff700d4a62eff724d3af9a2987c |
@alanz Maybe you don't need it anymore. But I'm sending something like this: {
"jsonrpc":"2.0",
"id":"1",
"method":"client/registerFeature",
"params":{
"registrations":[
{
"id":"4165c42a-1ced-49b0-b2fd-ad08bca1702c",
"method":"workspace/executeCommand",
"registerOptions":{
"commands":[
"sts.vscode-concourse.codeAction"
]
}
}
]
}
} |
FYI: I have updated my SO question with an answer that provides a summary of what I have learned. Hopefully it can save someone else some time figuring this out :-) |
What I have is the response to {
"result":{
"capabilities":{
"textDocumentSync":1,
"hoverProvider":true,
"codeActionProvider":true,
"renameProvider":true,
"executeCommandProvider":{
"commands":["applyrefact:applyOne"]}}}
,"jsonrpc":"2.0"
,"id":0
} The in the {"result":[{"title":"apply hint:Redundant do","command":"applyrefact:applyOne"}],"jsonrpc":"2.0","id":4} No parameters yet, but it arrives as an |
@alanz Ah that's interesting. I used the 'dynamic capability registration'. I didn't know you can also register your commands via the 'initialize response'. That's actually slighlty simpler if you don't need the commands to be registered dynamically (which I don't). Thanks for the info. |
The big thing that is missing in this spec is scenario based flows, so you can see how it is intended to be used. cc @dbaeumer |
As far as I could figure out, implementing a quickfix via a language server isn't really possible. I think this is a shortcoming of the protocol. Though I'm not really sure about that. It could just be I'm missing something.
I tried getting some answers here: http://stackoverflow.com/questions/43328582/how-to-implement-quickfix-via-a-language-server
But got no replies.
Anyhoo. The problem seems to be the following:
The closest thing we have to implementing quickfixes is via
textDocument/codeAction
.But... this only allows the server to request that the client executes some command on the client-side to perform the 'quickfix'.
There seem to be a number of problems with this kind of an approach:
So my conclusion is, this is rather broken / impossible at the moment. Wonder if it could be fixed.
One idea is that protocol should offer some mechanic similar to how content-assist completions work. I.e. a 'code action' item should provide the means to be resolved to some document or workspace edits when the user invokes it.
PS: I did manage to implement a some quickfixes, following exactly the mechanism described in the SO question. I.e. I defined a client-side command that executes a quickfix by sending back the info attached to it back the the language server using some custom protocol. The server then responds with workspace / document edits to be applied, which the client-side custom command then applies to the workspace.
The text was updated successfully, but these errors were encountered: