-
Notifications
You must be signed in to change notification settings - Fork 400
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
No delegateCommandHandler for java.apply.workspaceEdit #376
Comments
Yeah documenting jdt.ls specific commands is in our backlog (#314), sorry about that.
Basically, the server sends workspace edits to the client, and the client is responsible for applying them. |
Isn't that how code actions work? Why do you need a special command for that? |
I think the issue is that protocol doesn't specify clearly how client is going to consume a
sourcegraph/javascript-typescript-langserver chosen option 1 and LanguageClient-neovim followed the same pattern. And it looks here eclipse.jdt did option 2. |
So much for having a unified protocol that solves the matrix problem... |
The main difference between 1 and 2 is when the |
But option 2 doesn't conform with the protocol.
If the need for option 2 is real shouldn't it be pushed to the protocol? |
There is a proposal to support returning an edit instead of a command: microsoft/language-server-protocol#178 |
This provision was added AFTER jdt.ls implemented code actions this way. So "option 2" was at one time in the protocol, but was removed. We should probably move to using WorkspaceEdits, now that the can contain resource changes, but that would break existing clients. |
Hi guys - any update on this one? I see that lots of other clients are busy implementing custom commands (i.e. autozimu/LanguageClient-neovim#158) which as mentioned above is unnecessary. Won't most clients be able to handle WorkspaceEdits now? If so then moving across should be fine? Cheers |
What makes you think that? |
I saw the linked ticket had been closed back in August. But if most have not then it would have to wait, yes. (https://github.com/prabirshrestha/vim-lsp this one for instance does seem to) |
Was testing JDT-LS integration with LSP4E and ran into this issue as well.
Also, could we retitle this issue to something like |
If client advertises `CodeActionLiteralSupport`, using that for `java.apply.workspaceEdit` would allow clients to use a generic algorithm, instead of being forced to provide a special case for jdt.ls. Fixes #376 Signed-off-by: Boris Staletic <boris.staletic@gmail.com>
The fix was reverted because of a regression. See #1256 (comment) |
If client advertises `CodeActionLiteralSupport`, using that for `java.apply.workspaceEdit` would allow clients to use a generic algorithm, instead of being forced to provide a special case for jdt.ls. Fixes eclipse-jdtls#376 Signed-off-by: Boris Staletic <boris.staletic@gmail.com> Signed-off-by: Anton Romanov <theli.ua@gmail.com> Signed-off-by: Roland Grunberg <rgrunber@redhat.com>
If client advertises `CodeActionLiteralSupport`, using that for `java.apply.workspaceEdit` would allow clients to use a generic algorithm, instead of being forced to provide a special case for jdt.ls. Fixes eclipse-jdtls#376 Signed-off-by: Boris Staletic <boris.staletic@gmail.com> Signed-off-by: Anton Romanov <theli.ua@gmail.com> Signed-off-by: Roland Grunberg <rgrunber@redhat.com>
- If client advertises `CodeActionLiteralSupport` for the given kind, simply return the code action. Otherwise, set the command as `java.apply.workspaceEdit` - Fixes eclipse-jdtls#376 Signed-off-by: Boris Staletic <boris.staletic@gmail.com> Signed-off-by: Anton Romanov <theli.ua@gmail.com> Signed-off-by: Roland Grunberg <rgrunber@redhat.com>
I'm using jdt.ls via LanguageClient-neovim, and I'm trying to use code actions. This is my file:
JFrame
is linted because I did not import it, and the LS suggests some code actions(this is from the log of the client - I just formatted the JSON lines to make them readable):So I pick
Import 'JFrame' (javax.swing)
:And get the error message -
No delegateCommandHandler for java.apply.workspaceEdit
The LSP specs does not seem to refer to
delegateCommandHandler
s, and from #346 it looks like it's jdt.ls' extension - but I don't see any instructions on how to use it.So... what do I need to do to add support for it in a client?
The text was updated successfully, but these errors were encountered: