Reduce the fuzzying

[peterbe]

I typed continue in python and this suggestion popped up:

The highlighting inside the autocomplete suggestion tooltip seems to indicate that it found it because of the Co and the nt and the i and the n and the u and the e.
But it's totally different! :)

When I have typed so much ("continue" is 9 characters), couldn't the fuzzyaldrin (or whatever it's called) take that into account? It'd make sense to suggest "CommentsBySignature" if I had typed co (or even con with one edit distance).

This is not a rare case. Just that I really noticed it this time because it's a great example of how overly optimistic the fuzzying matcher is.

[peterbe]

So, why do I "complain"?

Well, suggestions are easy to ignore if the next thing you do is to type a space character.
But in this case, after having typed continue in Python I'm going to hit Enter to go to the next line and if I do that it replaces my continue with CommentsBySignature which sucks so I have to always press Escape before I can finish that line.

[peterbe]

A more or equally pressing concern is; why isn't continue a alternative to autocomplete? It's been typed at least 4 other times in this file I'm editing and the word continue is common in the project. Much more common than CommentsBySignature.

[peterbe]

Sorry if I come across with a "tone". I love autocomplete-plus and it often saves me typos because the guesses are pretty good.

[jeancroy]

Hi peterbe.
I believe it's OK to allow very fuzzy result as long as obvious result come first.
And certainly continue would rank before CommentsBySignature

So what happens here ?
One possibility is that some provider will not suggest what is already typed. IE continue is not on the list because there's nothing to complete from the typed continue

If you type cont an continue does not appear, then it's a different issue.

[peterbe]

If I type continu (missing the last e) it certainly suggests continue but the other suggestions are incredibly far from relevant.

If have bothered to type 8 characters I have really started to form an opinion on what I'm going to type.

I think the fuzzying matcher needs to take this into account. The number of edit distances between continu and CommentsBySignature[:8] is 6 which should tell it to give up IMHO.

[jeancroy]

For a spell checker, your suggestion would be a perfectly valid behavior.

However sublime text among other popularized selecting using a sub-sequence. This is what you see.
In your particular case it does not make much sens, but it use the same rule as when it does make sens. As long as the obvious answer is on top the other results are not much important.

What I start to gather is that it is easy to do an accidental accept of auto-complete. Maybe the key binding / timing is the underlying issue. Maybe the rule that hide continue while already typed is a problem.

[winstliu]

Maybe the rule that hide continue while already typed is a problem.

If it's shown, that's also an annoying issue, because you'll need to hit enter twice instead of once when trying to get to a new line.

[peterbe]

If it's shown, that's also an annoying issue, because you'll need to hit enter twice instead of once when trying to get to a new line.

"enter twice"?? You mean, first Escape (to kill the autocomplete) and then Enter. This happens almost always when I type a multi-line comment.

[jeancroy]

If it's shown, that's also an annoying issue, because you'll need to hit enter twice instead of once when trying to get to a new line.

Among the two evil I believe pressing enter twice is better than having the current word replaced by something else unintentionally. (And probably having to press enter twice anyways).

The hide prefix if already typed rule is also the cause of that case sensitive confusion #42

And possibly the source of people not wanting autocomplete to be enabled #552

---

I'm starting to think a Primum non nocere approach might be what we need. Like if the auto-complete is automatically triggered, do not select any result by default, let enter do it's job of making a newline.

[jeancroy]

And to be fair with peterbe, we are not totally powerless in accepting those fuzzy matches.

Usage of the sub-sequence feature is mostly useful on acronyms.

So a rule like

• at least half the letter must
• be part of either a word boundary
• or a group of at least two consecutive letter

could set a baseline for relevance. The problem is that your bad results would pass that rule. We can bump it to 3/4 but then ssrb would barely pass. It's hard to but a minimum accuracy without sample of what people use.

[peterbe]

I very much like the idea that Enter after typing doesn't select the first autocomplete suggestion. I these days often find myself typing something then Escape then typing something then Escape to get rid of the overly eager autocomplete.
Prior to Atom I used an editor where I always had to make a conscious choice to find autocomplete suggestions. An advantage with that is that it rarely gets these terrible examples (e.g. continue !!= CommentsBySignature) and that the IDE doesn't use so damn much resources. :)

[peterbe]

The ssrb example is tricky because on one hand "Set Syntax" and the "ss" makes sense because they are initials. However, the "Ruby ~= rb" example is pretty nifty.

However "ssrb" is only four characters, so there's still a chance that autocomplete will help me. However "continue" is 9 characters. If I've typed that many characters before I contemplate the autocomplete options I think I've made up my mind more.

In the same sense, I've I've taken the time to type CaseSe I've committed to bother to type uppercase and I've typed a lot so I would not like it to suggest "casesensitivity" as an autocomplete option.

If, inside the fuzzyaldrin "engine", there's some sort of threshold, it would be good if that could become dynamic. E.g 4 edit distances max if you've type 5 or more characters, otherwise 6 edit distances. Or something like that.

[peterbe]

Again, thank you for your patience. The code is awesome. But it can still be improved. I'm just speaking straight from my gut and that's from real actual use.

[jeancroy]

If I've typed that many characters before I contemplate the autocomplete options I think I've made up my mind more.

The thing is a query with a lot of character could be

• user already typed what was needed. (As you suggest)
• user need to type a long query because of multiple similar result
• user just have a preference for long query.

For example:
LctFnMxm could match LocateFunctionMaximum
Query have 8 chars, 13 edit distance, but otherwise perfectly valid.

[peterbe]

I have to admit, this practice of typing things like "LctFnMxm" is new to me. Maybe I'm just an old fart.
I can't think of any other applications where I explain autocomplete to break apart what I've typed. E.g if I type Aaaa it could technically find "AlAbAmA" but I can't imagine it being something many users would expect when they type "aaaa".

Is there a name for this? Could enabling/disabling that be an interesting configuration option?

[jeancroy]

What I meant is that just like ruby can be shortened as rb, function can be as fn, javascript as js, pointas pt, pixel as px, control as ctrl, button as btn and so forth. And it's not impossible to mix and match those in a query.

One thing that does not help is that fuzzaldrin is used by many part of atom: In "command palette" you know you are selecting so it's OK to type as few letter as possible (like ssrb). In "fuzzy finder" people type query mixing folder and file name, even sometime without a / and expect things to just work. In "autocomplete" however, normal word will get passed to the fuzzy engine for no other reason than waiting 100ms. And that might cause accidents if it's too easy to accept a match.

[jeancroy]

Limit on the number of error is very hard to set. For example LCM -> LocateFunctionMaximum is 18 edit distance. While continue -> containsUE is 2 edit distance (UE = user exprerience?). So nothing really make us safe from unwanted replacement.

Visual Studio Code (which is basically a Microsoft clone of atom) have an interesting way to handle fuzzy matching. I from what I understand, one can either add a character to existing sequence or jump to the next word. For example having typed LF the 2 legal option to match LocateFunctionMaximum would be u or M

As an added bonus that kind of fuzzy but still rigid allow to precompute a search index.

[jeancroy]

Ok i've checked against sublime text which is seen as having a good auto complete. (sorry for image size)

1. Suggestions discussed here are shown.
   

2. Continue allow to stay (and yes we need to enter twice)
   

3. Uppercase not strictly enforce but rank better.
   

[wmayner]

IMHO:

• The super-fuzzy substring matching is a fantastic feature (though it does take some getting used to), and it's consistent with the behavior elsewhere in Atom, and in other apps (e.g. Sublime or the YouCompleteMe completion plugin for Vim).
• As others have pointed out, the real problem is the Enter keybinding.

Proposed Solution: Only the Tab key should accept suggestions!

Pros:

• Keep it simple, stupid! One less behavior to figure out, implement, and maintain; one less keybinding to keep track of.
• Principle of least astonishment (as you say, the current behavior is pretty astonishing).
• Consistent with the command-line.

Cons:

• Inconsistent with other menu selection boxes.
• I'll leave the rest of these up to you folks 😸

EDIT:
As it turns out, there's already setting for this in the package! Just set your Keymap For Confirming A Suggestion to tab instead of tab and enter. This should arguably be the default, even though Enter would make sense to a user that hasn't been bitten by this yet.
And, if you don't like that solution, there's a “reduce the fuzzying” option in the settings as well—Use Strict Matching For Built-In Provider—though I'd really recommend getting the hang of the superfuzz instead; it's awesome.

[peterbe]

It's not easy. But there's certainly something fishy about the Enter command.

Often, my "frustration" (ie. things we can improve) stems two scenarios.

1. When I have typed a full term that already exists but is not the first choice. Hitting enter to start a new line overrides what I had painstakingly typed.
   
   In this example, it was maybe a mistake to type out the whole of forms and not hitting Tab + Enter when I had typed form because without the s the word forms was the number one suggestion. Now that I've typed it, to get to a new line I have to Esc + Enter rather than just Enter.
2. Similar, if I type a new word that has not been typed before. But said word is the start of another word.
   
   Now I can't hit Enter because hitting Enter will accept the first suggestion. However, it's only a problem when I have to hit Enter.

[peterbe]

Hmm... Maybe both of my above mentioned frustrations can both be solved by changing the setting so that Tab is what selects from the suggestions. Thanks @wmayner I'll look into that.

[xdumaine]

This one is frustrating me quite a bit

[peterbe]

If this discussion is leading anywhere it's that it's frustrating when the top-most suggestion isn't the word itself, if the word itself has been written somewhere before.

So, it's not a matter of "boosting" the words "continue" or "else" or "Environment" to be the first choice because they don't even show up. @xdumaine I'm guessing this isn't the first time you've typed "else" in that project/file.

[xdumaine]

Right, so basically if the word is an exact match, then that exact match should be the first result, and the confirm action should choose it, not some other fuzzy match.

[jeancroy]

@peterbe @xdumaine Is it possible you are using fuzzy provider instead of symbol ?

Because that behavior is fixed for symbol I beleive:

[peterbe]

I'm apparently using "Symbol". Version 1.0.11

[jeancroy]

Using a clean install of atom, python language:

Sorry about the huge screenshot.

[peterbe]

That's exactly what I want! What version and what default provider is that?

[xdumaine]

I just ran all updates and it seems to be working now. None of the updates looked like they were relevant, so now I'm stumped.

[13rac1]

@wmayner 👍 tab to accept by default.

The default autocomplete-plus autocorrect behavior is quite frustrating. Example:

1. Make a new file named: example.sh
2. Type:

EXAMPLE="words"

#This example

Now press Enter after that last e and the entire word becomes capitalized to EXAMPLE. It gets worse though, because autocomplete pulls from other open files (which is great, don't get me wrong!). Example:

1. Leave that original open
2. File->New File
3. type the text example
4. Press Enter to make a new line (the way that you make new lines in every other program.) Result:

EXAMPLE

The expected way to select auto-complete is tab as suggested above or the arrow keys. I know I can change to tab, but I really think this default functionality needs to allow users to type newlines in the expected way.

Edit
I just realized the default functionality, arguably, doesn't work the way described in the instructions.

Just type some stuff, and autocomplete+ will automatically show you some suggestions. Press UP and DOWN to select another suggestion, press TAB or ENTER to confirm your selection.

[irbdavid]

I am surprised to see that purely numeric 'words' are included in the autocomplete dictionary, as I think this is as likely to cause problems as it is to save time. A setting to disable this would be very welcome.

[eedwardsav]

Symbol Matching still isn't working as expected...

[Ben3eeE]

@leroix Do you think this is addressed by subsequence and the removal of the fuzzy provider?

[jeancroy]

hi @Ben3eeE what we see here is that snippet (green arrow) appears before symbols.
It does this by design even if a lot of us kinda disagree of that design.
#465

[leroix]

@eedwardsav @Ben3eeE I believe this particular situations would be fixed in Atom 1.22. It's worth giving it a try.

[Ben3eeE]

@leroix The suggestions from autocomplete-snippets still sort first and fuzzy even when using the subsequence provider.

I am going to close this in favor of #465 thanks @jeancroy for the issue link 🙇‍♂️