-
Notifications
You must be signed in to change notification settings - Fork 30k
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
Comments
+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. |
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.
@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? |
I based a repo and file picker off the 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
} |
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: Shall i create a separate issue referencing this, or is it enough to leave this comment here? |
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 |
#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. |
@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 |
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?
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. |
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.
I'm strongly in favor of a. |
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. |
@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.
This is an example of #3 Adding |
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
Amusingly I actually use this bug to remove recently opened without moving my fingers from the home row. |
|
@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:
|
@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 :-) |
@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 |
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 :) |
👍
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. I don't understand how "RevisionBehavior" gets ranked higher than "RemoteVideoBehavior", given the input of |
can we add something like order: highlight: |
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.
|
Another issue related to "go to file": #81250 |
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 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 |
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 However, there is one improvement as of version 1.44: if you put in a space instead of a slash ( This leads me to believe that something with the directory separator is overriding the "give more emphasis to capital letters" logic. 🤷♂️ |
Great suggestion @curtisgibby! IntelliJ already does it. |
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. |
Numerous issues have been filed on this topic, merging them into one:
File Picker
Command Palette
Picker (extensions)
Editor History
Symbols
The text was updated successfully, but these errors were encountered: