-
Notifications
You must be signed in to change notification settings - Fork 401
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
Take advantage of CodeActionLiteral client capability #1256
Conversation
Can one of the admins verify this patch? |
Done. I just forgot to commit the test. |
There are compile error.
|
...sts/src/org/eclipse/jdt/ls/core/internal/handlers/CodeActionHandlerUseWorkspaceEditTest.java
Outdated
Show resolved
Hide resolved
The build errors should be fixed, but I keep getting:
whenever I try to build jdt.ls. |
There is still one compiler error:
|
I can't reproduce it. |
Fixed, hopefully. |
It is the same. You have to run:
before pushing the PR. |
I know I should, but like I mentioned, I had a problem with downloading a |
It works for me, but someone else must approve. |
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.
I'm OK with changes. One comment is to add the test cases into CodeActionHandlerTest.java
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>
@bstaletic thanks for your contribution, keep 'em coming! |
Since the PR was approved by 2 devs, I merged it before actually testing it myself. Big mistake! 1st time I open a file in vscode I get no code actions and see this in the log:
I could see that
|
This reverts commit 2a2e09b. See #1256 (comment)
@fbricon So the If I'm not mistaken, this patch should fix that bug: diff --git a/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CodeActionHandler.java b/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CodeActionHandler.java
index 71e66b8..6521962 100644
--- a/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CodeActionHandler.java
+++ b/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CodeActionHandler.java
@@ -187,6 +187,7 @@ public class CodeActionHandler {
}
Command command;
+ boolean commandContainsWorkspaceEdit = false;
if (proposal instanceof CUCorrectionCommandProposal) {
CUCorrectionCommandProposal commandProposal = (CUCorrectionCommandProposal) proposal;
command = new Command(name, commandProposal.getCommand(), commandProposal.getCommandArguments());
@@ -199,12 +200,13 @@ public class CodeActionHandler {
return Optional.empty();
}
command = new Command(name, COMMAND_ID_APPLY_EDIT, Collections.singletonList(edit));
+ commandContainsWorkspaceEdit = true;
}
if (preferenceManager.getClientPreferences().isSupportedCodeActionKind(proposal.getKind())) {
CodeAction codeAction = new CodeAction(name);
codeAction.setKind(proposal.getKind());
- if (preferenceManager.getClientPreferences().isSupportedCodeActionLiteral()) {
+ if (preferenceManager.getClientPreferences().isSupportedCodeActionLiteral() && commandContainsWorkspaceEdit) {
codeAction.setEdit((WorkspaceEdit)command.getArguments().get(0));
} else {
codeAction.setCommand(command); Since it's the quickest thing I could write to see if my assumption is right, would you mind testing this patch before I push it? |
If client advertises
CodeActionLiteralSupport
, using that forjava.apply.workspaceEdit
would allow clients to use a genericalgorithm, instead of being forced to provide a special case for jdt.ls.
Fixes #376
This actually tries to revive #1059. Differences compared to #1059:
isSupportedCodeActionLiteral()
instead ofisWorkspaceApplyEditSupported()
.isSupportedCodeActionLiteral()
and I took the chance to fix the docstring from a previous faulty copy/paste.