Quick Open Too Generous

[cfsilence]

When searching for a file named "common.js" the following result should not be included:

http://screencast.com/t/QsuizsgUOz

Quick Open should search strictly for the string in its entirety.

A nice enhancement for Quick Open would also be to support searching via capital letters similar to the way you can in Eclipse.

For example, searching for "TIMC" would find both a filename that contained that string, but would prioritize the file name: ThisIsMyController.txt because I searched for the capitalized letters.

[rajeshsegu]

To make it easy, it should just search for the file names only. In IntelliJ, its done a lot better..

First show all the best match file names and in the later section show all possibilities.

[ctolkien]

I'm a huge fan of the 'search by capital letters' method.

[njx]

Reviewed. Assigning to @dangoor, and /cc @larz0 for thoughts on this. Seems like there are two issues:

• filenames with an exact prefix match should sort to the top: I like this idea.
• search by capital letters: I thought we did this already--it generally seems to work for me. @dangoor, do you know of cases where this wouldn't work?

[larz0]

I agree with all the suggested improvements.

[dangoor]

In #3588, I'm in the midst of work for code hinting that adds new options to Quick Open. I can look into scoring adjustments that benefit prefixes of the filename. Already, however, a prefix match in the filename is heavily boosted.

@rajeshsegu Quick Open originally searched just in filenames. This made it really hard to use, because it's not uncommon to have to wade through lots of similarly-named files in different directories. By including the directory in the search, you get better results. Note that matches in the filename get a boost, so they're more likely to get to the top.

@cfsilence I can understand the argument about possibly filtering out matches that are pretty poor. My focus with Quick Open has been to make sure that the best matches are near the top and I didn't worry about poor matches appearing farther down the list.

If you have a file called ThisIsMyController.txt and you type timc, the current algorithm should float that to the top (regardless of which directory it's in). Give it a try and let me know if it doesn't for some reason.

Summarizing what I see above:

The original problem reported is just that a file that is a match, though not a good one, appears in the list.

We could fix that, but it seems low priority.

Does anyone on this thread have a case where the file they're looking for isn't at the top of the list? If so, please let me know which file (including the full path in your project) you wanted at the top and which ones were ahead of it. It's impossible for the algorithm to guess 100% which file is intended, but there's always room for improving how close it gets you to a given file.

[njx]

Here's an example I just ran into which is probably similar: in the nj/extension-removal branch (as of 73e24e9), do Quick Open for "emv.js" (intending to get ExtensionManagerView.js). If you just type "emv", you get the right hit at the top, but adding the ".js" suddenly brings another item to the top: "mv.js" buried deep in a folder structure that happens to have an "e" somewhere far up the chain.

I feel like a lot of the odd matches I get are of this form: the end of the query matches stuff in the filename, but stuff earlier in the query matches random characters from the rest of the path. I almost wonder if it would be better to require there to be a "/" in the search in order to match separate path segments.

[peterflynn]

@njx I'd suggest just penalizing the score rather than filtering out completely. Sometimes what I remember as the filename turns out to be the folder name (happens especially often with code moved into extensions), and it's nice to still get results in that case.

[dangoor]

@njx I wouldn't want to have to explicitly add a "/", because I'll type things like "jschm" to get JavaScriptCodeHints/main.js.

The current algorithm does get some strange matches, but my concern has always just been to have the best at the top. I would not be opposed to penalizing strange matches and filtering out matches that are below some threshold if we want the list to look cleaner.

[njx]

Yup, I agree that penalizing cross-segment matches that don't have "/" in the query would be better than requiring "/".

[dangoor]

This should be fixed at the same time as #3971

[njx]

Reviewed, removing 1.0 milestone. Doesn't seem critical to improve the heuristics further right now.