Suggest should show exact match first (case insensitive)

[octref]

• VSCode Version: Code 1.9.1 (f9d0c68, 2017-02-08T23:31:51.320Z)
• OS Version: Darwin x64 15.6.0
• Extensions:

Extension	Author	Version
concrete	vscode	0.1.10
vscode-eslint	dbaeumer	1.2.6
tslint	eg2	0.8.1
Theme-TomorrowKit	ms-vscode	0.1.3
debugger-for-chrome	msjsdiag	2.5.4
vetur	octref	0.3.8
vuehelper	oysun	0.1.0
vscode-icons	robertohuertasm	7.2.0
language-stylus	sysoev	1.6.0
vim	vscodevim	0.5.3

---

This feels really weird. If one starts by typing "line" he would expect methods starting with line instead of spline.

There is also an exact match (case insensitive):

[bpasero]

I have tons of issues that ask for improving this for quick open and IntelliSense is also similar but currently uses its own custom solution. Maybe about time to convert to one solution... Unfortunately there are different contexts with different ideal sorting/scoring (files vs commands vs methods) and on top of that there is everyones own custom opinion what should come first.

[jrieken]

Today IntelliSense scores like this

		// combine the 4 scoring values into one
		// value using base_100. Values further left
		// are more important
		return (CompletionModel._base ** 3) * caseSensitiveMatches
			+ (CompletionModel._base ** 2) * caseInsensitiveMatches
			+ (CompletionModel._base ** 1) * (CompletionModel._base - firstMatchStart)
			+ (CompletionModel._base ** 0) * (CompletionModel._base - highlights.length);

So what you see is expected because line sensitive matches count the most. Before making further changes we need a sound model describing what factors (match index, match count, camel-case match, contiguous match, case-sensitivity etc) count how.

[octref]

I don't have enough knowledge about all the issues around IntelliSense so I can't help much with the sound model, but I'd argue case-insensitive match at the beginning should score higher than case-sensitive match in the middle.

Also, Vim's smartcase (http://vim.wikia.com/wiki/Searching) is really useful. Maybe VSCode can also do scoring case-sensitively if completion input has any uppercase char, and case-insensitively if input has no uppercase char?

[jrieken]

closing this as dupe of #22153

[tylerstillwater]

I'm not sure how this is a dupe of #22153. The other issue discusses fuzzy matching, where this one discusses exact match case insensitivity and case-insensitive starting characters matching.

I would expect the same behavior for the case-insensitive example given for .line -> .Line as it's an exact word match when case is not taken into account.

As mentioned above it is more complicated than that, but at the same time this is what feels completely intuitive to me, so I am hoping something can be done about it.

Obviously people are used to how vscode is scoring matches now, so it may be best, assuming this is implemented, to make it an option. intellisense.matchWholeWords:true or somesuch.

[octref]

@jrieken I'm unlocking this in light of #43464:

I don't think #22153 covers this. When I type out a word if there is a suggestion that's an exact match, it should have the highest score.

Can we reopen this, or are you interested in opening a mega issue that covers all scoring issue as @bpasero suggested?

I have tons of issues that ask for improving this for quick open and IntelliSense is also similar but currently uses its own custom solution. Maybe about time to convert to one solution...

[jrieken]

Please file a separate issue, this issue has nothing to do with the current implementation anymore...