search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.37k stars 28.61k forks source link

Improve ranking of elements in quick open #27317

Open bpasero opened 7 years ago

bpasero commented 7 years ago

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

File Picker

Command Palette

Picker (extensions)

Editor History

Symbols

kumarharsh commented 7 years ago

+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 commented 6 years ago

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

@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 commented 6 years ago

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

keegancsmith commented 6 years ago

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 commented 6 years ago

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?

bpasero commented 6 years ago

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

WickyNilliams commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@bdjnk

bdjnk commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@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

costincaraivan commented 5 years ago

My ticket was closed for being a duplicate of this one.

I'll repost it as a comment as I'm not sure I see how this ticket covers my feature request/improvement:

I've renamed a top-level folder (don't remember if I did it within VS Code or outside of it, I'm not sure it matters much).

Unfortunately now when I search for files, I get both the results in the old folder (which fail to open, obviously, and they're removed from the search results, afterwards, through the popup) and the ones in the new folder.

Is there some way to manually trigger re-indexing of files so that the search results are up-to-date? It's kind of annoying when you have tens or hundreds of files moved around.

dcecile commented 5 years ago

Not sure if this has already been covered, but I'd like to see a separation between local and library symbols when using the global symbol search (#). Something like the screenshot above where "recent files" show first?

For example, here my local symbol is mixed in with library symbols, and it's past the first page of results:

image

eypsum commented 5 years ago

I updated #62435 I can never search even with full matching name

!! Symbol Search look Fatal Error

eypsum commented 5 years ago

I updated #62435 I can never search even with full matching name

!! Symbol Search look Fatal Error

Sorry, There is syntax error, so I fixed it and can find the symbol.

madprops commented 5 years ago

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 commented 5 years ago

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.

xqin commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

Another issue related to "go to file": https://github.com/microsoft/vscode/issues/81250

jkillian commented 4 years ago

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 commented 4 years ago

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. :man_shrugging:

Nowaker commented 4 years ago

Great suggestion @curtisgibby! IntelliJ already does it.

madprops commented 4 years ago

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.