Allow for camel case matches in editor history

[Cardinal90]

• VSCode Version: 1.49, 1.50, 1.51 insiders
• OS Version: Windows 10

Starting in 1.49 recently opened behavior in the quick open panel changed for me. For example, here is a screenshot of me trying to open the C_Unit.cs file:

I never type the underscore. The file is not on top - fair enough (I don't remember if the order was the same before, but that's not the point). So I pick the file I need and go about my day. Some time later I want to open that same file again. I type the first letter, and there it is, recently opened:

The problem is that I don't normally type one letter, I'm used to typing cunit to open this particular file. And as soon as the letter u is typed, the C_Unit.cs file disappears from top never to be seen again. The panel looks the same as in the first screenshot, and I have to pick the file manually again. Prior to 1.49 update it was always shown as recently opened along with several other files starting with C_.

Does this issue occur when all extensions are disabled?: Yes

[bpasero]

This is actually intentional to reduce the chance of history results getting higher ranking compared to other results from the workspace. We intentionally do not match fuzzy on history entries:

vscode/src/vs/base/common/fuzzyScorer.ts

Lines 44 to 52 in 8ff399e

	if (!fuzzy) {
	if (!targetLower.includes(queryLower)) {
	// if (DEBUG) {
	// console.log(`Characters not matching consecutively ${queryLower} within ${targetLower}`);
	// }
	return NO_SCORE;
	}
	}

Related previous issue on this topic: #100590

[Cardinal90]

I investigated and found this commit: 611f6f9. The camel-case-matcher, which you mention in #103052 (comment), was successfully matching cunit against C_Unit.cs. I have to say that calling that camelCase stretches the definition somewhat. The heuristic was very vague there, it just happened to help my use case.

I see that you made more changes after that, so now the code you posted prevents the match anyway. Would you consider allowing a perfect match on alphanumeric characters only? It seems reasonable to me at the moment. I don't know what other cases it would break though. It's probably impossible to satisfy everyone here.

[bpasero]

Thanks for the bisect, let's leave this open as feature request. I also added it to #27317