Skip to content
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

Modified to use WorkspaceEdit on OrganizeImports. #1059

Conversation

mikoto2000
Copy link

This PR is part of #376.

Modified to use WorkspaceEdit on OrganizeImports if client supported workspace/applyEdit.

Needed those client capabilities and initialization parameters for use WorkspaceEdit.

  • kind: quickfix
    • workspace/applyEdit is true
    • textDocument/codeAction/codeActionLiteralSupport/codeActionKind/valueSet contains quickfix
  • kind: source.organizeImports
    • workspace/applyEdit is true
    • initializationOptions/extendedClientCapabilities/advancedOrganizeImportsSupport is true

@eclipse-ls-bot
Copy link

Can one of the admins verify this patch?

@fbricon
Copy link
Contributor

fbricon commented Jun 2, 2019

Test this please

@fbricon
Copy link
Contributor

fbricon commented Jun 2, 2019

@mikoto2000 can you please sign the Eclipse ECA and sign-off your commit?

@fbricon fbricon modified the milestones: Mid May 2019, Mid June 2019 Jun 3, 2019
@mikoto2000
Copy link
Author

Okay. I will sign ECA and add Signed-Off-By.

@mikoto2000 mikoto2000 force-pushed the use_workspaceedit_on_organizeimports branch from 4c2004b to 03e80cc Compare June 4, 2019 12:27
@mikoto2000
Copy link
Author

I added Signed-Off-By.

@fbricon fbricon requested a review from yaohaizh June 5, 2019 23:32
@yaohaizh
Copy link
Contributor

yaohaizh commented Jun 9, 2019

This might break the organize imports if the organize coming with commands such as resolve ambiguity . @testforstephen Please help review this one for organize changes.

@mikoto2000 Please find document for code action carefully: https://microsoft.github.io/language-server-protocol/specification#textDocument_codeAction These two edits & commands are not mutually exclusive.

Copy link
Contributor

@yaohaizh yaohaizh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need review from @testforstephen

CodeAction codeAction = new CodeAction(CorrectionMessages.ReorgCorrectionsSubProcessor_organizeimports_description);
codeAction.setKind(CodeActionKind.SourceOrganizeImports);
codeAction.setCommand(command);
if (preferenceManager.getClientPreferences().isWorkspaceApplyEditSupported()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getOrganizeImportsAction is used for advanced organize imports (Prompt a UI for resolve ambiguous imports). The command it returns is java.action.organizeImports, not java.apply.workspaceEdit. If you don't implement the command in the client side, please keep initializationOptions/extendedClientCapabilities/advancedOrganizeImportsSupport to false.

What you need look at is the function convertToWorkspaceEditAction.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What you need look at is the function convertToWorkspaceEditAction.

Thank you.
I was misunderstanding advanced code action function...

I want to work organize imports, without client-side command implementation.
so I will no fix getOrganizeImportsAction.

I check convertToWorkspaceEditAction and try fix it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed 7890248 and af1be20.

@mikoto2000
Copy link
Author

I fix SourceAssistProcessor#convertToWorkspaceEditAction to use WorkspaceEdit if client supported workspace/applyEdit.

List of support WorkspaceEdit commands:

  • Organize Imports
  • Override/Implement Methods
  • Generate Getter and Setter
  • Eclipse proposal(e.g. Remove 'unusedField', keep assignments with side effects)

List of no support WorkspaceEdit commands:

  • Generate hashCode() and equals()
  • Generate toString()
  • Generate Constructors
  • Generate Delegate Methods

Condition of using WorkspaceEdit:

  • workspace/applyEdit is true
  • initializationOptions/extendedClientCapabilities/overrideMethodsPromptSupport is false
  • initializationOptions/extendedClientCapabilities/advancedOrganizeImportsSupport is false
  • initializationOptions/extendedClientCapabilities/advancedGenerateAccessorsSupport is false

Copy link
Contributor

@testforstephen testforstephen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's better to only add some different test cases, no need for duplicate code

}

@Test
public void testCodeAction_exception() throws JavaModelException {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test case is same as CodeActionHandlerTest. No need of it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

}

@Test
public void test_noUnnecessaryCodeActions() throws Exception{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as CodeActionHandlerTest. No need of it.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return server.codeAction(params).join();
}

public static Command getCommand(Either<Command, CodeAction> codeAction) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

duplicate with CodeActionHandlerTest.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return $;
}

public static boolean containsKind(List<Either<Command, CodeAction>> codeActions, String kind) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duplicated code. Use CodeActionHandlerTest#containsKind directly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mikoto2000 mikoto2000 force-pushed the use_workspaceedit_on_organizeimports branch from c7205e2 to da69be9 Compare June 16, 2019 20:33
Copy link
Contributor

@testforstephen testforstephen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@testforstephen
Copy link
Contributor

When this PR is merged, it may have some side effects for vscode-java client. Currently vscode-client used a customized applyWorkspaceEdit command to apply workspace edit to client, meanwhile it did formatting to the changed code block because of formatting issue redhat-developer/vscode-java#557.

But when switching to this PR behavior, the vscode will auto apply the workspace edit, but without formatting operation.

@mikoto2000
Copy link
Author

But when switching to this PR behavior, the vscode will auto apply the workspace edit, but without formatting operation.

Okay. I reproduced this behavior.

so I want to make format unnecessary after applyWorkspaceEdit.

I propose a solution.

Modify of eclipse.jdt.ls:

Add configurations.

  • java.format.settings.simple.tabSize
    • number of spaces that represents one tabulation
    • default is 4
    • if java.format.settings.profile or java.format.settings.url is not empty, ignore it.
    • (internal behavior): set to DefaultCodeFormatterConstants.FORMATTER_TAB_SIZE of JavaCore option
  • java.format.settings.simple.tabChar
    • tabulation character(tab, space or mixed)
    • default is tab
    • if java.format.settings.profile or java.format.settings.url is not empty, ignore it.
    • (internal behavior): set to DefaultCodeFormatterConstants.FORMATTER_TAB_CHAR of JavaCore option

CodeGenerator respect JavaCore settings so format unnecessary after applyWorkspaceEdit.

processing of vscode-java:

Use those value when initialize and change configuration.

  • editor.tabSize set to java.format.settings.simple.tabSize
  • if editor.insertSpaces is true, set space to java.format.settings.simple.tabChar
  • if editor.insertSpaces is false, set tab to java.format.settings.simple.tabChar

What do you think about it?

shun095 added a commit to shun095/vim-lsp that referenced this pull request Jul 4, 2019
@fbricon
Copy link
Contributor

fbricon commented Jul 16, 2019

Sorry but I need to better understand the new behavior before merging it, so I'll punt to target milestone to end of august

@fbricon fbricon removed this from the End August 2019 milestone Sep 2, 2019
@gns26
Copy link

gns26 commented Sep 4, 2019

Sorry but I need to better understand the new behavior before merging it, so I'll punt to target milestone to end of august

Any updates on this?

@fbricon
Copy link
Contributor

fbricon commented Sep 9, 2019

Sorry for the delay, I'm stretched on different projects and need to go through my backlog. But I haven't forgotten. I'll review as soon as I can.

@fbricon
Copy link
Contributor

fbricon commented Oct 7, 2019

Ok, I can look at it now, but after rebasing against master, the code no longer compile.

@fbricon
Copy link
Contributor

fbricon commented Oct 7, 2019

When this PR is merged, it may have some side effects for vscode-java client. Currently vscode-client used a customized applyWorkspaceEdit command to apply workspace edit to client, meanwhile it did formatting to the changed code block because of formatting issue redhat-developer/vscode-java#557.

But when switching to this PR behavior, the vscode will auto apply the workspace edit, but without formatting operation.

@testforstephen once #1194 and #1157 are fixed, the formatting issue should be fixed right?

@testforstephen
Copy link
Contributor

yes, these two issues should be able to fix it.

@mikoto2000
Copy link
Author

Ok, I can look at it now, but after rebasing against master, the code no longer compile.

Thank you.
I was able to reproduce the compilation failure.
I am going to check and fix it.

Signed-off-by: mikoto2000 <mikoto2000@gmail.com>
Signed-off-by: mikoto2000 <mikoto2000@gmail.com>
…spaceEdit.

Signed-off-by: mikoto2000 <mikoto2000@gmail.com>
Signed-off-by: mikoto2000 <mikoto2000@gmail.com>
Signed-off-by: mikoto2000 <mikoto2000@gmail.com>
@mikoto2000 mikoto2000 force-pushed the use_workspaceedit_on_organizeimports branch from da69be9 to aef4691 Compare December 1, 2019 11:26
@mikoto2000
Copy link
Author

I rebased from latest master(d30acc4).

codeAction.setDiagnostics(context.getDiagnostics());
if (useWorkspaceEdit) {
codeAction.setEdit(edit);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can easily throw a NullPointerException. If the proposal is either CUCorrectionCommandProposal or RefactoricCorrectionCommandProposal, there is no WorkspaceEdit created.

This is what happened in #1256 (comment) and was taken care of in #1278. Good luck.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants