Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve ranking of elements in quick open #27317

Open
24 of 64 tasks
bpasero opened this issue May 26, 2017 · 31 comments
Open
24 of 64 tasks

Improve ranking of elements in quick open #27317

bpasero opened this issue May 26, 2017 · 31 comments
Assignees
Labels
feature-request Request for new features or functionality quick-open Quick-open issues (search, commands)
Milestone

Comments

@bpasero
Copy link
Member

bpasero commented May 26, 2017

Numerous issues have been filed on this topic, merging them into one:

File Picker

  • Allow to paste a file path with symbol to go to symbol in file #123809
  • Allow to paste a file path with line number to go to line in file #123810
  • vscode ctrl+p show matched string: shows files but not able to see matched strings when file paths are long #123383
  • search files by name imperfect tokenization #116021
  • Keep order stable independent for how search is formed #123382
  • Opening files via relative paths containing parent directory, ".." #113322
  • Incorrect prioritization of filename suggestions in quick open dialog (Ctrl+P) #170353
  • Improve sorting of files in quick open #27028
  • Improved search in "Go to file" panel #25925
  • Quick open file order does not make sense as designed #92282
  • Prioritize filetypes containing code in Quick open / Go to file #49853
  • Quick Open strange highlighting #56667
  • Provide an option to disable fuzzy matching in file picker #2705
  • Add a setting to disable fuzzy matching in quick open #99171
  • Search for files should prefer findings in one piece #69648
  • index.js index.ts file should show at top of file picker when searching for the name of the directory #72514
  • Unexpected order of fuzzy find results with many consecutive matches #103889
  • Restrict quick open file to project files #19762
  • Bump quickOpen suggestions from current workspace to the top #38128
  • Sort workspace results over out of workspace results #116551
  • Sort results in "Go to file" by how close they are to the working file (usability) #5806
  • Rank exact match over history matches #106786
  • Allow to sort files alphabetical if score is identical #149780
  • Allow additional fuzzy search within files found via CTRL+P #39542
  • Go to file: prefix with / to prefer results in root #81250
  • Allow quick open to filter on folder names by typing folder name after the file #30404
  • Scorer is not very good for matching on filenames #12095
  • Sort order for file quickopen should prefer shorter paths #17443
  • Quick open highlight should match consecutive characters better #21019
  • Improve quick find algorithm to prioritize exact matches better #26649
  • QuickOpen (Ctrl+P) search matching logic needs to be improved #33247
  • How to locate one of several files of the same name #32918
  • File list order not correct in go to file #34210
  • fuzzy searching problem #36119
  • Fuzzy search results are not prioritized well. #36166

Command Palette

  • Unable to search the command palette with special characters #118469
  • Command Palette - Match Commands by ID #113165
  • Command palette should rank results with closer search terms higher #14727
  • Add fuzzy search to commands in palette #1964
  • Adaptive abbreviation search for quick open commands #17697
  • Command Palette should be filterable/customized by user-settings #38841
  • Adjacent characters are given a lower rank in command palette than distant #40044
  • Improve Command Palette search experience for word permutations #99685
  • Favorite Commands #101616
  • Command Palette search with + character (like "C++") doesn't behave as expected #123915
  • Quick commands fuzzy search doesn't work for text in brackets #27636

Picker (extensions)

  • Support custom QuickPick filter logic #90521
  • Ability to apply a final sort to QuickPick results #63050
  • Enable fuzzy matching for picker #34088
  • Broken fuzzy search highlighting/ranking for trimable strings #62918

Editor History

  • Allow for camel case matches in editor history #108446
  • Fuzzy search also in editor history #100590
  • Sort recently opened files by recency after I start typing #35610
  • Allow disable of recent history in "go to file" command #30770
  • Quick open changes order for matching elements #10690
  • Unintuitive result scoring with Ctrl-P in recent history #20546
  • Recently opened files is just a bucket and not sorted by recency #31591

Symbols

  • Allow extensions to fully control workspace symbol search (matching and highlights) #98125
  • Allow fzf style query in workspaceSymbols #106788
  • Add fuzzy search to search by symbol #33746
  • Lift the 60 chars limit on the camel case matcher #43338
  • Allow fuzzy result on searching symbol in file #62435
  • Allow to configure that "Go to symbols" sorts symbols by fuzzy match #69062
  • Improve ordering of "Go to symbol in workspace" results #71951
@kumarharsh
Copy link
Contributor

+1. With bigger projects, many files start getting similar names and searching for them via Ctrl+P becomes more and more tedious to the point that I find myself just using my mouse to hunt for files in the Explorer tree.

@d-akara
Copy link

d-akara commented Sep 18, 2017

I think there are a lot of issues here that might be interesting to look at in relation to the capabilities offered by this plugin built for Eclipse.
https://github.com/dakaraphi/eclipse-plugin-commander

  • Basically it is a more advanced sublime like command palette interface.
  • I am the author of the Eclipse plugin and would like to build an extension for VS Code with these capabilities. Although, I don't believe that is currently possible with current exposed VS Code API's

@bpasero would you be interested in making any of the features of the above plugin available to VS Code either by exposing API's to make it possible or adoption internally?

@imdadahad
Copy link

imdadahad commented Nov 21, 2017

Any news on #33746, it's one of the few things that's stopping me from switching over from Sublime 😬 @bpasero

@keegancsmith
Copy link
Contributor

I based a repo and file picker off the stringscore algorithm used in vscode, and ran into the same problems around poor ranking. What I did to solve this was reward items which are better "aligned" with the query. VSCode somewhat does this now in some places via sorting matches on the filename higher than just matches on the path, but that approach falls down when you have a query like workbench repo.ts since it has to fallback to the stringscore algorithm on the full path.

The algorithm I ended using you can think of somewhat like the stringscore algorithm right now, except it works from the end of the string, and works on the string split up by the path separator. I can implement this in vscode if there is interest. Here is the algorithm which I wrote (in Go, stringscore.Score is a port of the vscode algorithm, which is based off string_score)

// postfixFuzzyAlignScore is used to calculate how well a targets component
// matches a query from the back. It rewards consecutive alignment as well as
// aligning to the right. For example for the query "a/b" we get the
// following ranking:
//
//   /a/b == /x/a/b
//   /a/b/x
//   /a/x/b
//
// The following will get zero score
//
//   /x/b
//   /ab/
func postfixFuzzyAlignScore(targetParts, queryParts []string) int {
	total := 0
	consecutive := true
	queryIdx := len(queryParts) - 1
	for targetIdx := len(targetParts) - 1; targetIdx >= 0 && queryIdx >= 0; targetIdx-- {
		score := stringscore.Score(targetParts[targetIdx], queryParts[queryIdx])
		if score <= 0 {
			consecutive = false
			continue
		}
		// Consecutive and align bonus
		if consecutive {
			score *= 2
		}
		consecutive = true
		total += score
		queryIdx--
	}
	// Did not match whole of queryIdx
	if queryIdx >= 0 {
		return 0
	}
	return total
}

@WickyNilliams
Copy link

I'd like to add a suggestion to improve search: give more weight to capital letters. I believe sublime does this.

It's super handy when your files are named with PascalCase. Example, I have two files: MetaEditor.js and Menu.js. If i were to quick open with string "ME", I'd prefer MetaEditor to have a greater weight than Menu. This may be a bad example, because I'm not sure how much length is taken into account, but hopefully it illustrates the feature.

Shall i create a separate issue referencing this, or is it enough to leave this comment here?

@WickyNilliams
Copy link

Hmm.. yes, it does seem as though there is some preference given to capital letters. I think i was mistaken because recently opened files are given more precedence, even if other results are a better match e.g. I opened Menu.js recently, so that is top result, despite searching "ME" (for which MenuEditor.js be a better match?)

@bdjnk
Copy link

bdjnk commented Apr 10, 2018

#35637 was closed as a duplicate of #30770 and should probably be removed from the issue list.

Regarding those bugs, most irritating to me, currently open files pollute the "recently opened" section of "Go to File...". I often need another file with a similar name to one I already have open. This forces me to scan for it and mouse or arrow to it. This is blocking behavior for me.

I understand a comprehensive refactoring of file discovery is underway, but an option to disable "recently opened" in "Go to File..." seems like a relatively straightforward change.

@d-akara
Copy link

d-akara commented Apr 10, 2018

@bdjnk I find currently opened useful from recently open; however, I agree the current implementation of recents combined with all available files is not ideal.

When I built a command palette and file picker for Eclipse, I decided to keep them separate and use TAB as a quick toggle between them. I called these distinct views working and discovery modes The linked example is of the command palette, but the file picker called 'finder' works the same way. The working view contains a combination of recent + open + favorites. The discovery view is the list of everything.

@bpasero
Copy link
Member Author

bpasero commented Apr 11, 2018

@bdjnk

Regarding those bugs, most irritating to me, currently open files pollute the "recently opened" section of "Go to File...".

Can you explain that? What is the difference between "currently open files" and "recently opened"? That should actually be the same because each file you open becomes a "recently opened" file, no?

I understand a comprehensive refactoring of file discovery is underway

Not to my knowledge.

What we could do is a) add an option to remove the "recently opened" from the "Open File" picker and maybe b) have a second picker only for the recently opened ones.

@bdjnk
Copy link

bdjnk commented Apr 11, 2018

@bpasero

What is the difference between "currently open files" and "recently opened"? That should actually be the same because each file you open becomes a "recently opened" file, no?

Semantically, "recently opened" seems to me to imply no longer opened, but I can see how that's debatable.

Practically, if I have something open, I know I have it open and can get to it easily. Thus what I presumed to be the file discovery functionality showing me these files, in front of other file matches no less, surprised me greatly.

What we could do is a) add an option to remove the "recently opened" from the "Open File" picker and maybe b) have a second picker only for the recently opened ones.

I'm strongly in favor of a.
I'm mildly in favor of b, but would request recently opened discovery have an option to remove currently open files from the results.

@bpasero
Copy link
Member Author

bpasero commented Apr 11, 2018

Practically, if I have something open, I know I have it open and can get to it easily.

I would not agree, there are people that have tabs and "open editors" view disabled (like I do) and for me having something open is not relevant, I do not even see my "opened files". I use quick open with the "recently opened" section all the time to navigate between files I used last.

@d-akara
Copy link

d-akara commented Apr 11, 2018

@bpasero I think the issue I have with recent is subtly different @bdjnk

There are 3 areas where I find the behavior doesn't seem consistent or predictable.

  1. recents removes entries from the all list of files. This is sometimes a jarring experience when I want to see a view of all of some types of files. I can't see them listed together, some are at the top and others are somewhere else in the list. I would prefer the entries within recents to also remain listed in the all section
  2. The all section doesn't seem to be sorted by path, when you have items matched of same file name or equal rank. Makes it more difficult to conceptualize what files are grouped with what projects/folders etc.
  3. Sometimes recently opened just disappears from the list for certain pattern matches

This is an example of #3
image

Adding planning to narrow the selection completely removed the recents section which contained com.ibm.rqm.planning.service
image

@bdjnk
Copy link

bdjnk commented Apr 11, 2018

@bpasero

There are people that have tabs and "open editors" view disabled (like I do) and for me having something open is not relevant, I do not even see my "opened files". I use quick open with the "recently opened" section all the time to navigate between files I used last.

In your case, the fact that you have open files at all isn't apparent. It's an implementation detail. There I agree recently opened discovery is a critical feature.

I consider my projects like filing cabinets full of folders filled with documents. My open documents lay on my desk, so finding those is easy. Documents buried in the cabinet are where I need help.

What might be interesting is a "currently open" matches section at the bottom of the results. This could be helpful when I don't realize I have a document already on my desk.

@dakaraphi

Sometimes recently opened just disappears from the list for certain pattern matches

Amusingly I actually use this bug to remove recently opened without moving my fingers from the home row.

@d-akara
Copy link

d-akara commented Apr 11, 2018

@bdjnk

  • would it be correct to say what you specifically want is to be able to search everything not currently opened?
    or
  • do you just want to be able to visually see I already have this open in the existing list? In such case maybe a small icon or some type of visual annotation next to the file in the existing list would be satisfactory?

@bdjnk
Copy link

bdjnk commented Apr 11, 2018

@dakaraphi

I wouldn't mind the latter, and in certain ways it would be more intuitive. With additional consideration I don't disagree with your sentiment when you say:

I would prefer the entries within recents to also remain listed in the all section

@d-akara
Copy link

d-akara commented Apr 11, 2018

@bdjnk nice, as I also would find it useful to have some form some visual annotation/icon indicating if the file is already open. Also, this wouldn't change behavior that users have become accustomed to using, so maybe not a controversial change :-)

@ronjouch
Copy link

@bpasero can you add to the top-post meta issue "Match on workspace name, before or after file name" ?

For example, if I have workspaces foo and bar, both containing package.json files, typing either foo pack or pack foo should offer opening foo/package.json

@madprops
Copy link

madprops commented Mar 3, 2019

I think it would be very useful if when opening the Go To Symbol picker it showed the recently used ones at the top, instead of the current list that seems to be sorted alphabetically. This way it's easy to jump between stuff quickly without having to type too much :)

@curtisgibby
Copy link

I'd like to add a suggestion to improve search: give more weight to capital letters.

👍

@WickyNilliams we do that, see https://github.com/Microsoft/vscode/blob/ben/notifications/src/vs/base/parts/quickopen/common/quickOpenScorer.ts#L151

I'm confused by this, because I don't see it happening for myself. In the following example, I'm looking for the "RemoteVideoBehavior" in the behaviors directory.

fuzzy-search-camel-case

I don't understand how "RevisionBehavior" gets ranked higher than "RemoteVideoBehavior", given the input of beh/rvb.

@xqin
Copy link

xqin commented Aug 21, 2019

https://github.com/Microsoft/vscode/blob/release/1.37/src/vs/base/parts/quickopen/common/quickOpenScorer.ts#L390-L394

can we add something like matchesSuffix method to fix the following situation

order:

image

highlight:

image

@lukewlms
Copy link

lukewlms commented Sep 4, 2019

Regarding index.js/index.ts prioritization, I run into this every day and wonder if it couldn't be considered a high priority.

Using index.ts/index.js within directories is a JS best practice, but since VS Code deprioritizes finding these files when typing the directory name, it makes this JS feature nearly useless.

@Nowaker
Copy link

Nowaker commented Sep 20, 2019

Another issue related to "go to file": #81250

@jkillian
Copy link

jkillian commented Oct 3, 2019

image

Not sure if this has been covered exactly, but I also have run into some difficulties with the match scoring algorithm.

In the example above, I searched for modelforminstance which corresponds concretely to words in the file path I'm looking for (see the last two results).

However, all the highest ranked results are quite far off and have seemed to match after picking up single letters from the middle of multiple different folders.

I apologize that I don't know the code well enough to be more specific in the exact cause of this issue, but it feels like this is an area that could be improved and offer a lot of benefit to users, as file switching is such an important and common action

@curtisgibby
Copy link

I'd like to add a suggestion to improve search: give more weight to capital letters.

+1

@WickyNilliams we do that, see https://github.com/Microsoft/vscode/blob/ben/notifications/src/vs/base/parts/quickopen/common/quickOpenScorer.ts#L151

I'm confused by this, because I don't see it happening for myself. In the following example, I'm looking for the "RemoteVideoBehavior" in the behaviors directory.

fuzzy-search-camel-case

I don't understand how "RevisionBehavior" gets ranked higher than "RemoteVideoBehavior", given the input of beh/rvb.

I checked into this again after seeing that Quick Open was rewritten in 1.44. Unfortunately, I'm still seeing the same behavior as before: given the input of beh/rvb, "RevisionBehavior" gets ranked higher than "RemoteVideoBehavior".

However, there is one improvement as of version 1.44: if you put in a space instead of a slash (beh rvb), you get the expected results.

image

This leads me to believe that something with the directory separator is overriding the "give more emphasis to capital letters" logic. 🤷‍♂️

@Nowaker
Copy link

Nowaker commented Apr 8, 2020

Great suggestion @curtisgibby! IntelliJ already does it.

@madprops
Copy link

madprops commented Jul 26, 2020

The way it is right now is hard to work with. When I ctrl+p I always intend to go to a recent file I've just been editing. For instance I type 'style' to go to /tree/style.css but instead the first choice is /cloud/style.css, a file I probably edited once a long time ago, and pretty much I realize that it is not the correct file after opening it. Why wouldn't it pick the most recent one? Is the idea that, that use case should use ctrl+tab always instead?

Edit: I realized I could hit the X on the items that I didn't want to appear in the search, which helped. Also the main problems I had were because I had set the "main project" or what it's called to an older project which I wasn't working on anymore.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality quick-open Quick-open issues (search, commands)
Projects
None yet
Development

No branches or pull requests