Case sensitivity bugs

[alvinchow86]

It seems that once you've finished a "word", it gets removed from the list of candidates. But then what happens is if you hit "tab", what you've typed will get completely replaced with a very different word.

Here's an example in Java, with the words thread and Thread. When you start typing say the first few characters of thread, the primary suggested match is thread as expected, but when I type the last letter (d), it suddenly changes to Thread. Exact opposite thing happens when typing Thread.

Also in general, I think matching case should take higher priority for selecting the first match, or at least there should be an option. In this example, I think downloadThread should be the main suggestion instead of DownloadTask.

[peterbe]

I think downloadThread != DownloadTask and when you type dow it should NOT recommend DownloadAnything.

[saschagehlich]

Sorry, but I disagree. It's not a bug, it's a feature and I'm using it a lot.

I'll add a case sensitivity option, though.

[bblack]

👍 Case-sensitivity option is nice, but regardless, I think case-sensitive matches should appear higher in the list.

[janmarek]

Case sensitive matches should definitely have higher priority.

[jeancroy]

There are two issue in alvinchow86 post.

First two screenshot:
Both thread and Thread exist in the suggestion list but auto-complete remove suggestion that is exactly the same as typed. That mean you cannot accept a result from suggestion list and not change something. Pressing tab accept the first result.

Last screenshot:

Order of the results is handled by fuzzaldrin.

• Now fuzzaldrin do have a preference for proper case !
• However it also have a preference for shorter string.

And that is what explain current order.

The thing is, fuzzaldrin, while considering both factor, is HEAVILY biased toward shorter string. For example a single extra character is enough to prefer wrong case. See atom/fuzzaldrin#17.

PR atom/fuzzaldrin#22 would make fuzzaldrin (and thus autocomplete) more like you expect regarding case sensitive results. For example see this test

[glen-84]

+1

At a minimum, it should show matching case results first.

[jeancroy]

At a minimum, it should show matching case results first.

Only sometimes true.

For example typing inst against

• Install
• Uninstall
• input_status

Both matching case result are slightly worse than case-insensitive one.

---

However because both downloadThread and DownloadTask contain down as (a) consecutive letters (b) at start of the word then matching case definitively win.

[janmarek]

At a minimum, it should show matching case results first.

Only sometimes true.

It's always true when you use at least one capital letter in your query.

[jeancroy]

It's always true when you use at least one capital letter in your query.

I believe that's the convention vim YouCompleteMe use. (Actually only uppercase are forced case sensitive for YCM). I cannot immediately think of a counter example, nor a case where it would be needed on top of atom/fuzzaldrin#22 strategy.

For that PR, I went over like 50 real life issue of wrong ordering and added soft rules to fuzzaldrin. By soft rule I mean detect signal of match quality, and add bonus accordingly. Proper case are involved in many bonus, for exact case, acronym, exact substring etc. If you find a use case that is not covered by that PR, i'll be happy to either tweak bonus weight or add a new soft rule.

As for the proposed rule, it cannot be used to enforce all lowercase match like asked here: atom/fuzzaldrin#17. And also it might be confusing because typing a single uppercase letter can change the meaning of every other typed letter so far.

[glen-84]

Only sometimes true.

I was referring to cases where "install" actually exists, but it puts the proper-case version ahead of it for some strange reason.

[jussi-kalliokoski]

Sorry, but I disagree. It's not a bug, it's a feature and I'm using it a lot.

How is this not a bug? :D

Reminds me of having autocorrect on in Skype as in it makes more incorrect corrections than the people using it make typos. I'm not saying fuzzy matching is a bad thing, and I don't want to disable it, but this can't be right, I get bitten by this several times per hour.

[bakape]

Definitely a needed feature. foo = new Foo() is a very common pattern and not having a case sensitivity option is counter-productive.

[benogle]

@bakape can you enable the Use alternate scoring option in autocomplete-plus? Does that solve it for you?

[bakape]

@benogle Oh, it does. Thank you!

[jnunemaker]

@benogle oh my, the alternate scoring is life changing. The lack of case sensitivity has been driving me nuts from the beginning of atom.

[benogle]

👍 It will be the default in Atom 1.4. There is the same option in the fuzzy finder as well.

[jeancroy]

@benogle should we pin the version number then ? I don't want to push a change that bypass quality control, beta, etc.

Pretty confident about 0.3.1 now.

[benogle]

Yeah, feel free to update the version and the default. It hasnt been updated in this package yet, only fuzzy finder.

[GroovyCarrot]

This now appears to be "Use Strict Matching for Built-In Provider" in autocomplete-plus

[winstliu]

Looks like this has been solved.