Setting to disable autocompletion fuzzy matching altogether

[queeniema]

Issue Type: Feature Request

Sometimes, it is annoying to see completely unrelated results when using autocomplete. See the attached screenshot. I am expecting a pure search (ie, consecutive characters only), but am seeing a lot of results pop up simply because they share the same letters.

VS Code version: Code 1.29.1 (bc24f98b5f70467bc689abf41cc5550ca637088e, 2018-11-15T19:06:21.742Z) OS version: Darwin x64 18.2.0

[jrieken]

I am expecting a pure search (ie, consecutive characters only), but am seeing a lot of results pop up simply because they share the same letters.

That's not the design because people prefer to type the important letters to get as fast as possible to the suggestion they want. However, matches are sorted by quality and those strict prefix matches are atop. I don't understand what the problem here is.

[queeniema]

Thanks for the reply. Please ignore this request, the most important thing is that the "startsWith" results appear first (and they do).

[ransagy]

I still suffer from this greatly. In my example, I use the SQLTools extensions, which provides the list of column names for tables, etc in my DB. As far as i'm aware, Extensions don't control this behavior; just the list of information provided for completion.

Trying to complete something as simple as MyID matches tons (and show them FIRST) of columns that are: exactly ID (but not MyID), contains the word ID or have capitals of M and I (or something similar i didn't quite understand) in their name. For reference, There are MyID suggestions in the list, But they are buried beneath a ton of other, irrelevant suggestions (all column names proivded by the extesnions, not snippets or other element types).

So the mentioned behavior by @jrieken doesn't seem to work in my case (VSCode 1.33, editor.suggest.filterGraceful set to false) at all and makes intellisense completely painful.

[jrieken]

@ransagy filterGraceful is not what you think it is. To clarify

• fuzzy filter - given a prefix bk match blank, black-knight, e.g. match all query character in order, ranked by match score eg black-knight is better than black-knight
• graceful filter - account for typos in the query, esp swapped character, e.g. cno is matched as cno and con using fuzzy filter

So, fuzzy filter and graceful filter are orthogonal, e.g. you can replace fuzzy filter with e.g prefix filter and still have graceful filtering. This issue is about a stricter score/match function, not about graceful filtering (which already today is configurable)

[ransagy]

@jrieken Thank you for the clarification. Just so i'm groking this fully - Should the current, in-place fuzzy filter work for the situation i described (and that i do believe is related to this issue) or is the scoring/matching changes discussed here are a possible way to attain that? Your previous explanation seems to make it a possible bug rather than the wanted behavior even right now.

[jrieken]

Trying to complete something as simple as MyID matches tons (and show them FIRST) of columns that are: exactly ID (but not MyID), contains the word ID or have capitals of M and I (or something similar i didn't quite understand) in their name.

What's the prefix you have typed?

[ransagy]

My apology; i meant i physically typed MyID (as i wanted to see which tables have such a column) and the first results i got were Id, ID (our DB schema is not super consistent, sadly) and other things. A page or two into the results was MyID. I got similar results with a partial attempt (My).

[jrieken]

and the first results i got were Id, ID (our DB schema is not super consistent, sadly) and other things.

You should report that the extension creating those suggestions. By default, the label is used to filter and MyID definitely matches best against MyID. However, extensions can define a filterText which is used into filter/score (instead of label) and if you extensions does that (and does that in a bad way) then this could happen...

[ransagy]

@jrieken I'll report it there as well. Much appreciated.

[mtxr]

@jrieken I tried to fix @ransagy situation, in fact I'm using filterText, but I didn't find anywhere saying that it's a case insensitive match when using filterText, but it is. That's why the matches are not working.

Any suggestions on how to fix it?

[jrieken]

but I didn't find anywhere saying that it's a case insensitive match when using filterText, but it is. That's why the matches are not working.

That would be very surprising but without information I cannot tell. Given about samples of MyID, ID, Id what filter text values would the three have?

[jrieken]

Kind of answered this myself, looks like the name table name is always prefixed but I don't know what values they have but that's like the cause here. @mtxr Why did you chose to prefix the table name? Is that something you want/expect users to type?

[mtxr]

Here is it:

With filter text enabled:

With falsy filter text:

I bellieve anyScore is changing the match for insensitive here: https://github.com/Microsoft/vscode/blob/ca13e25b42132c7b6cd8f2255babd4b6bf56c1b9/src/vs/editor/contrib/suggest/completionModel.ts#L209-L221

[mtxr]

@jrieken yes, some users want to type table names, I don't like it either, but in some situations it helps then to search.

I'm willing to remove table name prefix, but even using filterText = label, seems to be better if not use it at all.

EDIT: In fact without the prefix works, It just took longer for webpack to compile.

[jrieken]

I still need samples (values) for filterText

[mtxr]

accountability.myId company.MyId user.myID

@jrieken in fact you are right, prefixing it is making it not work as expected.

Is the anyway I could achieve this or only removing prefixes? I understand why prefix is breaking it, I'm pretty sure remove will be the only fix :D just want to confirm

[jrieken]

@jrieken in fact you are right, prefixing it is making it not work as expected.

You seems to talk about the blue'ish highlights and anyScore as "not working". That's kind of expected because with filterText you tell us use a string to filter/score which we don't render. We use anyScore to display at least some blue highlights on screen but they don't reflect what has matched.

Also note that @ransagy talks about sort order - which depends on filterText and sortText not about highlights.

Is the anyway I could achieve this or only removing prefixes

Yes and no - filterText works best when it's less than the label, not more. E.g. a label is @foo but the filter text is just foo (so that user don't have to type @). In your case, you filter on more than the UI shows that hard to achieve (how would a user know).

Maybe you should reconsider how you complete with table names, e.g only when the prefix matches a table name and then also show the table name as label, or use as label myId - users.myId but as filterText and insertText just myId etc

[mtxr]

@jrieken thanks!

I've already updated that.

[dequation]

Problem still persists.

There should be a setting to disable fuzzy matching altogether. I also get for instance PushButton suggestion when trying to create the variable button1 in guizero.

That changes the IntelliSense from helpful to annoying.

Also, as a sidenote, I have trouble imagining a system of string matching where 'try/except' would be a better match for 'Text' than 'Text' is. Reminds me Apple's Spotlight Search.

[muirdm]

Chiming in with another use case for this feature. gopls (the Go LSP server) does server side fuzzy matching and intelligent candidate ordering. The VSCode fuzzy matching/ordering sometimes changes the order of gopls candidates in unfavorable ways (see https://github.com/microsoft/vscode-go/issues/2739#issue-491376188). It would be nice if we could make VSCode use the provider candidates verbatim since the provider might be ranking candidates using better heuristics than text matching alone.

[dequation]

Still relevant. Fuzzy matching is providing often very irrelevant suggestions, constituting noise. Turning it off should be an option.

Example: Trying to write .minsize(), FM will provide the option to add a code snippet ("__main_\"). Contextually that suggestion is pure nonsense, and means I have to do an extra keypress to suppress. There are tons of other examples. The try-except code snippet is particularly annoying, popping up everywhere.

There can be absolutely no harm in allowing us to turn off fuzzy matching, and simply use graceful filtering.

Please add this feature.

[FriedrichWeinmann]

To chime in on it: Fuzzy filtering is one of my greatest headaches so far. Often there actually is no exact match for what I'm typing (because the intellisense can't know it all). In those cases, being offered other fuzzy matches is a major annoyance, as it interferes with my typing.

e.g.: PowerShell. If I want to type the following line without actively cancelling the intellisense window:

begin
{

}

What I get thanks to fuzzy-match is this:

bdechangepin.exe{

}

yay.

[justin-anonuevo]

Hi, this feature is infuriating for me. I tend to work in files, not projects since the platform I work on is hosted somewhere else and I do not have source code, I just put in my own code (I use ServiceNow). Having said that, there a number of 2 letter classes, like gs I have to use. Those always turn into get selection, which I do not want.

I know this is super help if you have a full project, or take the time to define every possible class you could use, but that is just not our workflow. Having the option to turn the fuzzy logic off would be fantastic. In the mean time, it is just infurating.

As I write scripts, I do like the direct match, especially if I document with JSDoc. But the fuzzy match is not worth the headache.

This feels like the editor is trying to much to be a full IDE (like visual studio not code) by forcefully expecting you to have everything set up, and basically tell you that you are wrong if you just want to build a quick script.

-Justin

[xaxazak]

This should be reopened IMHO.

• Many different posters here different reasons why fuzzy completion is annoying them, and how very much it is annoying them.
• Adding an option to disable this should be very easy.

I don't think many options are crucial, but this one should definitely be near the top of the user-benefit per dev-time list.

[miliarch]

I think a disable setting is warranted - while I like many things about VS Code, this aspect is frustrating, and I'd like to turn it off.

My anecdote for the thread:

I was scaffolding a python function, planning to return to it later. A common strategy I employ when doing this is dropping in the pass statement to satisfy the interpreter. Typing pass resulted in "fuzzy autocompletion" returning the name of another function in the file - calculate_proportional_dimensions:

I was perplexed when I pressed enter and pass was not present, but that function name instead. Twice more I tried, twice more I was thwarted by a tool that was supposed to be making my life easier. I remembered that I could press esc to dismiss a completion suggestion (a persistent thorn in my side since switching to VS Code), which allowed me to add the word I desired to that line of the file. (30 seconds)

I began my search on google to find what setting was responsible so I could disable it. I quickly found an article about IntelliSense, and while it didn't give me an answer, it lead me to a keyword I could use in VS Code settings (30 seconds). Searching intellisense in settings I found many "Editor > Suggest" setting variables, but none that seemed to fit. Searching suggest in settings lead me to my new favorite setting - Editor: Accept Suggestion On Enter - which solved the issue I mentioned earlier (60 seconds). Perusing the rest of the settings I found a few that seemed like they might fit, but weren't quite right in testing (Filter Graceful, Suggest On Trigger Characters, Emmet's Show Expanded Abbreviation). (300 seconds). I returned to google, and came across this thread (300 seconds).

All in all, from discovery of the issue to identification that I could not disable fuzzy matching, I spent approximately 720 seconds (12 minutes). Include this comment, which I feel that I have to make on principle, and I've easily invested 30 minutes into this problem. Many other users, evidenced by participants in this and linked issues, have also spent a significant amount of time not just being annoyed enough by it to search out this issue and request a change, but to figure out what the mechanism behind the issue is in the first place. If I can lend credence to our cause, I have to try.

This is a user experience issue that should be solved by inclusion of a setting that allows the user to disable fuzzy matching. Maybe call it "Editor > Suggest: Matching Mode" so users can easily find it in settings, and include options strict, sequential, and fuzzy.

Thank you for hearing me out.

[gjsjohnmurray]

@miliarch I feel your pain. A couple of years back in #85768 I proposed the following which might have helped you:

How about extending editor.suggestSelection to accept a new value none ?

With this, you'd have had to press down-arrow followed by Enter if you wanted to accept the suggestion. Unfortunately it didn't attract enough upvotes to get onto the Backlog.

[ransagy]

Always nice to circle back and see that a "glaring" usability issue (as confirmed by multiple users with multiple different use cases) still exists for the lack of simply allowing us to disable a feature.

Just for curiosity sake - Is there some resistance/pushback from the VS team on having the option to disable this? Is it significantly more complex than all of us are imagining to implement, either in engineering work (from the design/architecture aspect) or time wise? Is it just a matter of priority, despite this seemingly being a very quick "fix" to do?

Will a PR to add this even be considered? (I'm not suggesting i'm going to do just that, for lack of time myself, but it's an important point to clear, IMHO)

[miliarch]

I do suspect it's not a trivial change, but I also suspect it's far from difficult. Maybe 40 hours of effort to familiarize, design, implement, and test. Priority would be my guess. Most users seem to be happy with the default suggestion behavior (noisy users / all users = very small percentage), meaning low negative impact to product success, and the negative consequence to the noisy users is simply time spent, which depending on their level of familiarity with the product may be required for them to learn to use it effectively at a base level. To phrase differently, there is small incentive to cater to this group of users based on all-too-common metric based prioritization techniques.

This is an open source project, theoretically any of us can fork this repo, set up a development environment, and start making/testing changes. If we successfully implement a better behavior, we can submit a pull request and hope it passes scrutiny for a merge. I'm not well-versed in TypeScript or electron application development, and I get the sense that most of us impacted by this aren't either, so we're essentially looking/waiting for a hero :).

I did a bit of digging and I think these files are likely the ones that need extending/adjusting:

• https://github.com/microsoft/vscode/blob/main/src/vs/base/common/filters.ts
• https://github.com/microsoft/vscode/blob/main/src/vs/editor/contrib/suggest/browser/suggest.ts
• https://github.com/microsoft/vscode/blob/main/src/vs/editor/contrib/suggest/browser/completionModel.ts

[ransagy]

Contextually, The original suggestion was a killswitch - disable the feature, i.e. the code path. Essentially just no-op instead of doing the fuzzy match algorithm. I don't imagine how doing that should take so much work . Having said that, As you suggested, I have not worked much with TS (despite 15+ years of csharp experience) and not at all with electron.

Either way - I wouldn't even try to figure it out unless the VSCode team showed willingness to accept such a change.

[miliarch]

Ah yes, good observation/grounding there - I've got a grander scheme in mind for usability than a simple on/off switch for the current suggestion matching algorithm. You're probably right that effort would be trivial to modify behavior in that way.

My only doubt is that disabling fuzzy matching would mean disabling suggestion matching as a whole. My hunch is that fuzzy is the only option, meaning a consecutive match (as described in the original request) is not a fallback in its absence.

I've opened #141224 to reflect my more complicated suggestion :)

[ransagy]

I've noticed that the new issue @miliarch kindly created has become a backlog candidate - so for the sake of people involved in this thread and have not noticed the new issue yet - please go and up vote if you support the idea as it relates to this issue so it might get looked at. Thanks!