Use history relevance when sorting completions based on the usage of those completion items

[gayanper]

When working with Unit Tests we tend to use the Assertions.assertThat() method a lot. So when I type assertThat I expect the suggestion with mostly used method in my current test to be on top instead of the order of methods in the Assertions class.

[fbricon]

I like the idea, but implementing it would lead to pretty convoluted conversations between the client and the server.

First, the server has no clue about which completion was selected and applied, only the client knows.
And a client like VS Code provides no way for extensions to know which completion was selected.
Now there's a trick that might be possible:

• have the client advertise to the server which command to apply client-side when completion is selected, as a client capability, let's call it onCompletionAppliedCommand
• if onCompletionSelectedCommand is set, then jdt.ls could return every completionItem with the matching command name
• when the client applies the completion, it would then call its own onCompletionAppliedCommand implementation, which in turn would call a jdt.ls custom command (say java/completionItemApplied)
• In jdt.ls java/completionItemApplied would keep track of the selected item, incrementing some stored relevance data
• on next completion request, jdt.ls checks the stored relevance info, increases previously used completion relevance, sends it back to the client

This might lead to some perf degradation as this would add one more roundtrip on every completion, I dunno, but that's how it could work

[testforstephen]

I vote for smart code completion based on context and history.

Currently jdt.ls already supports returning the selected completion item without adding additional client-side code. IntelliCode has adopted this behavior.
https://github.com/eclipse/eclipse.jdt.ls/blob/0e79bc49f77b06765232c4a474a71e048401569a/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/CompletionHandler.java#L123

[rgrunber]

Similar request in redhat-developer/vscode-java#3341 . I don't like the approach of tracking it ourselves because I think searching by references in the search engine (index) would be much nicer. The problem is obviously performance. There's no way we can search each type/method immediately on the completion request to set sortText.

What if we created our own index category table (or augmented the existing type/method decl. ones) that mapped a given type/method decl. to the number of times it's referenced in the project ? That lookup should be easier, and it shouldn't add that much more time to the indexing because we already index all the references anyways.