[Request] Auto-Import Priority

[rhystedstone]

I've been using VSCode for Java development for the past 5 years, and I keep having the friction when working with an API - there's no (obvious) way to prioritise one package over another.

I'd like an option to provide a list of type filter-strings which organise the imports based upon those filters - like how java.completion.filteredTypes operates:

All types whose fully qualified name matches the selected filter strings will be ignored in content assist or quick fix proposals and when organizing imports. For example 'java.awt.*' will hide all types from the awt packages.

Simply put, if I put org.bukkit at the top of the entry, then suggestions from org.bukkit.* should be at the top of the import list, so you can just hit [Enter], rather than having to select the correct option.
I.e. I only use, and will probably only use the second option, yet there's no way to prioritise that package:

As I've mentioned, I'm aware of filteredTypes, but I don't want these types filtered in-case I want to use them later-on. Being able to prioritise types, such as an importPriority option, would allow this problem to be fixed in-general, for any project, rather than having to set filteredTypes for every project individually.

[fbricon]

Ideally the import priority should be determined by the existing code usage. I see this import priority setting as a clutch to compensate for the language server not being "smart" enough to offer the best prioritisation. Might be a necessary clutch in the end (e.g. for greenfield projects) but I'd like to see if we could improve that prioritisation. @rgrunber @jjohnstn @snjeza shouldn't the indexer do that already?

[rgrunber]

Basically similar/duplicates to #3414 , eclipse-jdtls/eclipse.jdt.ls#1423 , eclipse-jdtls/eclipse.jdt.ls#2484 .

For symbol frequency, the indexer doesn't store how often a symbol is used, so you'd have to add a "category" to the index, or just cached the list somewhere on project import.

[rhystedstone]

Basically similar/duplicates to #3414 , eclipse-jdtls/eclipse.jdt.ls#1423 , eclipse-jdtls/eclipse.jdt.ls#2484 .

For symbol frequency, the indexer doesn't store how often a symbol is used, so you'd have to add a "category" to the index, or just cached the list somewhere on project import.

I agree these are similar, however I believe my suggestion of a list of packages would apply more broadly across projects - especially new projects, and would be much easier to implement.

This means you don't need to store the frequency of any symbol or package, and you wouldn't need to do any weird tricks to get the data from vscode, which should be a lot faster... at least theoretically; And again, new projects would benefit heavily since they wouldn't have enough sample data to create a useful frequency graph.

Not to mention, indexing the frequency for every project the user creates (in the same language) would get bogged down very quickly with the shear number of imports any somewhat-complex project uses.

For myself at least, the solution proposed in #3414 wouldn't help in 99% of my own circumstances. Funnily enough, it would fix the issue for the screenshot I provided, but I only chose that example because it was the first one to come to mind, and it represents a small fraction of cases where this occurs.

Sorry, didn't realise this comment would become 4 paragraphs 😃