Support advanced organizeImports to resolve ambiguous imports

[testforstephen]

Signed-off-by: Jinbo Wang jinbwan@microsoft.com

See PR redhat-developer/vscode-java#850 for vscode client implementation.

[testforstephen]

test this please

[fbricon]

we also probably want to have a default selection exposed in the API, for each list of choices (even though we might not want to return a default selection at this point. Think java.util.List vs java.awt.List

[fbricon]

I'd like to see the server response to look something like:

OrganizeImportsSelection:

• uri:string //file uri
• imports: list //hold list of choices/ranges/default selection per ambiguous import
  • default (null | int) //the index of the candidate to preselect
  • candidates: list
    • candidate: ImportChoice
    • range: Range

I believe it'll be easier to understand the API and implement the client side

[testforstephen]

Updated the client callback api schema:

• uri: string //file uri
• selections: list //hold list of choices/ranges/default selection per ambiguous import
  • candidates: ImportChoice[]
  • range: Range
  • defaultSelection: int //the index of the candidate to preselect

[yaohaizh]

The if conditional could be put insider getOrganizeImportsAction to make logic simple.

[testforstephen]

This if is to fall back to the old organizeImport logic if the JDT LS client doesn't implement chooseImports command yet. Don't belong to getOrganizeImportsAction function.

[yaohaizh]

CIL

[fbricon]

Now I'm having 2nd thoughts on the default selection. The problem with it is it adds more work onto clients to implement proper sorting, when it could be done at the server level, consistently for everyone. WDYT?

We could imagine the server will eventually guarantee a sort order based on a relevancy score.

[fbricon]

@yaohaizh CIL?

[yaohaizh]

When submit a review feedback, it requires comments, so CIL for comment in lines

[testforstephen]

Now I'm having 2nd thoughts on the default selection. The problem with it is it adds more work onto clients to implement proper sorting, when it could be done at the server level, consistently for everyone. WDYT?

We could imagine the server will eventually guarantee a sort order based on a relevancy score.

See

		 * Optional flag indicating if this item is picked initially.
		 * (Only honored when the picker allows multiple selections.)
		 *
		 * @see [QuickPickOptions.canPickMany](#QuickPickOptions.canPickMany)
		 */
		picked?: boolean;

vscode QuickPick only supports preselecting for multiple selections. And for single selection QuickPick, it will preselect the top one by default. So i did sorting to put the default selection to the top.

I like the idea of guarantee a sort order based on a relevancy score. If the server returns the sorted candidates list, then no need of defaultSelection field any more.

[testforstephen]

About calculating the relevancy of the candidate, one idea is to record the user picking history, and put the candidate in the history to the top. Also, if some class under the same package is existing in the history, give the candidate high priority.

In this PR, i removed the default selection logic, and add TODO tag about sorting. Will let a new PR to explore the sorting for the import candidates.

[fbricon]

Nice work @testforstephen!