code completion : rank options by usage

[doofin]

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

when using code completion,more frequently selected options are not ranked higher

Describe the solution you'd like

more frequently selected options are ranked higher

Describe alternatives you've considered

no

Additional contex

No response

Search terms

code ,completion ,rank,item,options,autocomplete

[tgodzik]

Thanks for reporting! That sounds like am interesting improvement. I wonder if it's the time we would try to employ some minimal machine learning or just do the rank by remembering the selections. Also I wonder if we actually have access to what was selected by the user 🤔

Anyway, this is an interesting proposal 👍

[olafurpg]

A lightweight implementation would be to use the referencedPackages bloom filter from ReferenceProvider

https://github.com/scalameta/metals/blob/944bf476ba33f4d4e9465fa6a8f441657a2e3bbb/metals/src/main/scala/scala/meta/internal/metals/ReferenceProvider.scala#L40

This bloom filter allows to cheaply test whether the codebase has at least one reference to any symbol under a package. It could be used to break a tie when ordering two symbols.

Metals already uses a fairly large number of parameters to determine ordering. You can see the list here for members alone

https://github.com/scalameta/metals/blob/944bf476ba33f4d4e9465fa6a8f441657a2e3bbb/mtags/src/main/scala/scala/meta/internal/pc/MemberOrdering.scala#L4-L17

The challenge with ranking is that you need to decide on the priority of each parameter. One risk with using dynamic parameters like "symbol usage" is that you get unpredictable ordering. I would caution against making the ordering metric super precise, for example keeping exact counts of all symbol usages.