Automatically complete the crate's name

[xmh0511]

crates seems not to support automatically completing the crates' name and listing all viable versions in order to select. It can just list all possible versions only if the full crate's name is input. Automatically listing all possible crates according to the input characters are useful and convenient. Hope that we can add this function.

[serayuzgur]

@BarbossHack What dou think? With sparse do you think there is a good way to do it ?

[BarbossHack]

Unfortunately I don't think there is a good way to do it with sparse index alone. We cannot search in the sparse tree, as it does not allow http listing (NoSuchKey when querying "bi" folder).

But as it won't generate a lot of requests (most of the time when you open Cargo.toml it's just to check version, adding features, etc... adding dependencies if often made with cargo add ..., or at least it needs a user interaction), so I think it should be ok to query the crates.io API here (what do you think @LawnGnome ?)

For example if we start typing "binco" (for bincode), the query would be :

curl -s "https://crates.io/api/v1/crates?page=1&per_page=5&q=binco" | jq -r .crates[].name

actix-bincode
async-bincode
bincode
bincode2
bincode_aes

By limiting answers to 1 page and 5 results it might be ok for crates.io

(And we can sort them by relevance, downloads, recent, recent update...)

[BarbossHack]

And if we don't want to use crates.io API, this feature could be implemented only for your custom index (with if !isSparseCompatible() { do autocomplete }).

[LawnGnome]

Yeah, I think you've hit the limit of the sparse index there.

The way the pagination and database interact, the number of crates returned is less the issue for us than the overall number of crates that match the search query. So I'm OK if you want to use the search API and also if you want to use a higher per_page number, but I think two things that would make it easier on crates.io would be:

1. Only start searching with a minimum number of characters (3 feels about right at a guess?), and
2. Some level of debouncing so the user has to stop typing before the request is issued (250 ms would probably be a good starting point), just so we don't get a rapid fire set of requests for bin, binc, binco, bincod, et cetera, as the user types.

Another thing we could do in theory would be to provide an endpoint that doesn't do the full text search, but just does a stem match (so you wouldn't get actix-bincode and async-bincode in your example; just the ones that actually start with binco), or provide an endpoint that just gives you crate names and nothing else, but let's start with the main search API and see where it gets us.

[BarbossHack]

Thank you for your answer !

3 minimum characters and 250ms seems good to me 👌

Another thing we could do in theory would be to provide an endpoint that doesn't do the full text search, but just does a stem match (so you wouldn't get actix-bincode and async-bincode in your example; just the ones that actually start with binco), or provide an endpoint that just gives you crate names and nothing else, but let's start with the main search API and see where it gets us.

Yeah, this would have been much better, but like you said let's start with the already existing search API

[loganmzz]

Any news about this issue ? Tried:

• https://marketplace.visualstudio.com/items?itemName=belfz.search-crates-io
• https://marketplace.visualstudio.com/items?itemName=jedeop.crates-completer
• https://marketplace.visualstudio.com/items?itemName=chenxuan.cargo-crate-completer

But none are working anymore.