New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Case sensitivity bugs #42

Closed
alvinchow86 opened this Issue Apr 17, 2014 · 20 comments

Comments

Projects
None yet
@alvinchow86

alvinchow86 commented Apr 17, 2014

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.

image

image

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.
image

@peterbe

This comment has been minimized.

Show comment
Hide comment
@peterbe

peterbe Apr 23, 2014

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

peterbe commented Apr 23, 2014

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

@saschagehlich

This comment has been minimized.

Show comment
Hide comment
@saschagehlich

saschagehlich Apr 23, 2014

Contributor

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.

Contributor

saschagehlich commented Apr 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bblack

bblack Jul 16, 2014

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

bblack commented Jul 16, 2014

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

@janmarek

This comment has been minimized.

Show comment
Hide comment
@janmarek

janmarek Aug 17, 2015

Case sensitive matches should definitely have higher priority.

janmarek commented Aug 17, 2015

Case sensitive matches should definitely have higher priority.

@jeancroy

This comment has been minimized.

Show comment
Hide comment
@jeancroy

jeancroy Aug 17, 2015

Contributor

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

Contributor

jeancroy commented Aug 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 Aug 19, 2015

+1

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

glen-84 commented Aug 19, 2015

+1

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

@jeancroy

This comment has been minimized.

Show comment
Hide comment
@jeancroy

jeancroy Aug 19, 2015

Contributor

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.

Contributor

jeancroy commented Aug 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@janmarek

janmarek Aug 19, 2015

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.

janmarek commented Aug 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jeancroy

jeancroy Aug 20, 2015

Contributor

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.

Contributor

jeancroy commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 Aug 23, 2015

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.

glen-84 commented Aug 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jussi-kalliokoski

jussi-kalliokoski Oct 2, 2015

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

screen shot 2015-10-02 at 09 38 01

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.

jussi-kalliokoski commented Oct 2, 2015

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

screen shot 2015-10-02 at 09 38 01

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

This comment has been minimized.

Show comment
Hide comment
@bakape

bakape Nov 17, 2015

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

bakape commented Nov 17, 2015

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

@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Nov 17, 2015

Contributor

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

Contributor

benogle commented Nov 17, 2015

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

@bakape

This comment has been minimized.

Show comment
Hide comment
@bakape

bakape Nov 17, 2015

@benogle Oh, it does. Thank you!

bakape commented Nov 17, 2015

@benogle Oh, it does. Thank you!

@jnunemaker

This comment has been minimized.

Show comment
Hide comment
@jnunemaker

jnunemaker Dec 8, 2015

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

jnunemaker commented Dec 8, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Dec 8, 2015

Contributor

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

Contributor

benogle commented Dec 8, 2015

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

@jeancroy

This comment has been minimized.

Show comment
Hide comment
@jeancroy

jeancroy Dec 8, 2015

Contributor

@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.

Contributor

jeancroy commented Dec 8, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Dec 8, 2015

Contributor

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

Contributor

benogle commented Dec 8, 2015

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

@joefitzgerald joefitzgerald removed this from the 2.1 milestone Feb 22, 2017

@GroovyCarrot

This comment has been minimized.

Show comment
Hide comment
@GroovyCarrot

GroovyCarrot May 31, 2017

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

GroovyCarrot commented May 31, 2017

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

@50Wliu

This comment has been minimized.

Show comment
Hide comment
@50Wliu

50Wliu Oct 25, 2017

Member

Looks like this has been solved.

Member

50Wliu commented Oct 25, 2017

Looks like this has been solved.

@50Wliu 50Wliu closed this Oct 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment