Better ordering for import code actions

[cdsmith]

Is your enhancement request related to a problem? Please describe.

Suppose I use Vector.toList without importing it. HLS highlights the error, and provides suggestions for where I might want to import Vector.toList from. Unfortunately, the list of possible import locations is extremely long, and therefore so difficult to use that I might as well scroll up and type the import declaration myself.

Describe the solution you'd like

Instead of listing all modules that export a toList, in alphabetical order, HLS would ideally notice that I'm attempting to qualify the import as Vector.toList, and prioritize modules with Vector in their name. I suppose it should also recognize the common patterns of using prefixes or first letters of different module components (e.g., Seq for Data.Sequence or LB for Data.ByteString.Lazy.

In the greatest generality, I think what I'd imagine here is a heuristic scoring function that determines how likely it is that I want to import from any given module, and then ordering the suggestions by that. Over time, this logic could be extended, for instance to prioritize modules that are already use in the project, or that belong to the same packages that are already used in this module, etc., and thus to function even for unqualified imports. Inevitably, I suppose, someone will eventually try to replace the heuristic with a machine learning ranking model... but at least just matching the proposed qualifier for qualified imports looks like an obvious win.

Describe alternatives you've considered

One disadvantage is that alphabetical order makes things easier to find, if people do actually scroll through the entire list of suggestions. Ways to mitigate this might include:

1. Only picking particularly good matches to promote to the top, but leaving most of the list in alphabetical order.
2. Only applying this heuristic when the list is beyond a certain length. For example, more than a dozen or two elements makes the list unusable in VSCode because it doesn't actually scroll at all, but instead extends beyond the bottom of the screen where most of it is unusable.

[michaelpj]

I think we can improve this iteratively.

A few other ideas for improvements

• Adding a member to an existing import is probably the canonical fix if there is one, and should be marked isPreferred
• Maybe we can tweak the code action titles to make them easier to scan, perhaps if we showed the "new" import instead of prose it would be easier

[michaelpj]

Perhaps another one of interest to @andys8

[ChristophHochrainer]

I want to work on it (munihac-2022) @fendor

[andys8]

Go for it 😉