Suggestions should favor case

[littlebee]

A typical pattern is to use CamelCase for classes and lowerCamelCase for variables. It would make my life at least 12% better if the top of the suggestions was the one that matched case. :)

(sorry, I don't see where to tag this as an ENHANCEMENT)

[jeancroy]

Do you have an example where case sensitivity is not preserved ? Do you have alternate scoring being turned on, if not is it fixed by it ?

[littlebee]

I will try and grab a screen shot next time I see it or at least get the specific words

[littlebee]

Here is an example:

[jeancroy]

Thank you for your report. Can you give us the package that generate those suggestions ? I believe it's not the default symbol provider. My guess is this is due because of https://github.com/atom/autocomplete-plus/issues/653

Here's the detail:

• With 3rd party autocomplete provider the default ordering is a mix between match quality and natural/initial order provided.
• As far as the match quality go, case is respected, see screenshot below that use the symbol provider, not subject to that mix.
• After the mix / compromise score the preference for proper case is somehow lost.

Some solution include

• Fixing the mix, the main problem I see is that I have no idea on how important the initial order should be. I alwais hear of it when there's a problem so my natural tendency would be pure match quality.
• Fixing the provider to it implement it's own sorting and bypass the compromise.

[littlebee]

my atom config is here: https://gist.github.com/littlebee/34a60734de79f6f78c56

I'm not sure which packages provide autocomplete. I had ctags installed for a while but it made the autocomplete suggestions more convoluted, so I went back to autocomplete-plus.

Here's another example:

[jeancroy]

I'll investigate for the first example, can you try to see if disabling the the autocomplete-plus Use Locality Bonus setting help this ?

For the second one, snippet (green arrow) always come first. See for example https://github.com/atom/autocomplete-plus/issues/465

[lenart]

Not sure if this is the best thread but I'd like to give another suggestion for the autocomplete ordering. It would be best to order the autocomplete options by the number of characters matching. When there are multiple suggestions the shorter ones should come first.

From screenshot above I'd prefer if do would come before dop since it exactly matches my input.

This way one could maybe also control the ordering by re-assigning less used autocomplete options to a longer keyword. Maybe others have better suggestions on how to do this but it's just something that bugs me daily.

[winstliu]

@lenart that is a different issue that should be fixed in the 1.6.0 betas.

[lenart]

Allright @50Wliu, thanks for clarifying. I've downloaded beta 1.6 and can confirm this has already been resolved.

[ghost]

I can confirm this for the php-integrator-autocomplete-plus package as well. For example, if I provide class and function suggestions (in that order) and type array, I get:

I can switch the order of both providers, but this somehow doesn't feel right. There is no fuzzaldrin filtering happening in the providers (all the suggestions are returned and the filtering happens via autocomplete-plus). I also have no suggested context-based priority for them; the user is typing something in a global scope, so both functions, constants and classes are relevant here. As autocomplete-plus is doing the actual fuzzy matching and filtering, it also feels as if it should be taking care of the sorting as well (it is already determining relevance of matches based on the fuzzy matching, after all).