Better autocomplete ranking: Exact matches shouldn't de-prioritize macros & results should prioritize local namespace items

[kurtbuilds]

I have two major suggestions to improve the autocompletion results from Rust-analyzer.

Using rust-analyzer (from Zed), constants, functions, and statics are prioritized over macros when doing an exact match, often with quite surprising results.

For example, try to autocomplete panic:

rust-analyzer gives as the first result the core function panic, which end users should almost never use, instead of the obvious panic! macro. (Oddly, it also gives the panic! macro twice, a small bug.)

Likewise for format, the macro, which I would assume in 99% of cases what users want, is the 6th option.

Assert is similar to panic:

Personally, I'd love to see assert_eq ranked over assert. Note that a function assert_equal (which I haven't imported, but exists in namespace from itertools as a dependency) is prioritized over assert_eq.

It seems like macros are heavily de-prioritized. Here's autocompletion giving results for pr:

Which is a bunch of constants associated with a sql parsing crate that is a dependency but hasn't been imported anywhere in the file. Contrast the autocomplete results with those from IntelliJ for the same letters & position:

IntelliJ results are:

1. a "live template" with an exact string match for pr (what RA calls a snippet)
2. the macro println!, which in my experience, is used much more frequently than print
3. a local function parse_recipient
4. the print! macro
5. various other results that haven't been imported yet.

The intellij results are dramatically more helpful than the RA ones.

intellij seems to either have an embedded manual ranking, or it actually prioritzes longer matching strings over shorter. (E.g. pr ranks println before it ranks print). It's somewhat counterintuitive, but I see a compelling argument for matching longer strings before shorter ones: there are more characters to type, and therefore you prefer to rely on autocomplete more, when it's a longer string.

[kurtbuilds]

Closing b/c I think the frontend does ranking of results, not backend.

[flodiebold]

We can influence the ranking.

[kurtbuilds]

One other thing to add: I noticed it's quite nice how IntelliJ uses the import path as detail text if the item isn't in local scope.

[lnicola]

@kurtbuilds we have that too:

[kurtbuilds]

That's odd. What editor are you using in your screenshot? Zed is my go to, and import paths are not visible in the previous screenshots that I posted. Maybe it's only a Zed frontend issue then.