I'm not sure about this... the ctrl+p is more about searching and predictable repeatable results is very important. For the results to be different based on the file you have open isn't really obvious and like you said, breaks muscle memory.

We do have mechanisms in place for quickly switching like Ctrl+Tab to switch back to the previously opened file. These are deliberately selecting the 2nd item in the list because the gesture is that you hold down Ctrl+Tab and upon release it selects it.

....... with that said... let's see what others think.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@TylerLeonhardt I didn't know about Ctrl+Tab, thanks, it can be useful. The point of my issue is that having the current file as the top result when I search for a file is not useful; maybe it can be solved just like Ctrl+Tab does it - by selecting the second result if the current file comes up as the first result?

Is there an A-B testing facility for VSCode where we could check whether this change would harm anybody?

Is there an A-B testing facility for VSCode where we could check whether this change would harm anybody?

There is but it requires a chunk of setup. Because of this, I want to see if folks chime in on the issue first.

@TylerLeonhardt yes, of course. I didn't know there was such a facility for vscode; I know it cannot be trivial to set up.

Btw, there have been relevant comments from @nikita-r in #159301 .

I think your pointing out of Ctrl+Tab actually weakens the objection from #159301 that Ctrl-p Ctrl-p can be used to go to the previous editor, and it might on balance strengthen the evaluation that returning the current file as the first result isn't useful for quickOpen. That's why I see it more as a bug report than as a feature request.

what happens when the sidebar is focused though? is the last focused editor considered "current editor"? how would you move focus from the sidebar or the panel into the currently opened editor?

@nikita-r what would you say should happen?

There are other ways of focusing the editor when you're in the sidebar, e.g. "View: Focus Active Editor Group" workbench.action.focusActiveEditorGroup. I don't know its default keyboard shortcut, if it has any.

Therefore, my answer to your question would be that the editor that would get focused with workbench.action.focusActiveEditorGroup would be treated as the currently opened editor, and would not be the default result in quickOpen if any other results are available.

My issue speaks to how I understand the intent of quickOpen, not to the many other ways the action can be used.

My issue speaks to how I understand the intent of quickOpen, not to the many other ways the action can be used.

TBH you seem to concentrate on your particular use-case to the exclusion of other things, the most important of which, as Tyler said above, is being predictable/repeatable.

But since I keep being tagged in this discussion, I'll keep trying to convince you to close this issue :)

Let's say you have two files opened in two editor groups, side-by-side: ProductList.tsx & README.txt. You return to your computer after a break, so you don't remember which group is focused (and I don't think it is easy to tell at a glance,) and you press quickOpen. Would you be able to predict the files listing order once your proposed change is implemented?

I'm indeed concentrating on the behaviour of quickOpen after search, but I'm also careful to consider the possible habits of other users in various situations using this feature. Here's my reasoning.

On the surface, the quickFind feature relies mainly on recognition: the user types a query, sees a list of results, chooses the desired one. Muscle memory doesn't play a role here beside the basics of navigating a list. Maybe a stability of this list would be useful – e.g. for pairs of files, or groups of three like for Angular, that have the same name and different extensions, it could be good always to have the same order. But the current implementation primarily uses the order in which the editors were last open, so it does not give any such stability.

It's when the user has used quickOpen a number of times so it becomes possible to predict how much to type to get the right result, then press enter (which is a natural motion after typing a search query). This is the special case of a proficient user heavily engaged in a project, especially in the flow. In this situation, some users will prefer typing more in the query to having to move their hands to arrow keys or the mouse (compare with the HJKL keys in VI). This user in this situation is not looking to go to the currently active editor. With my proposed change, they will often automatically (without noticing) save keystrokes.

Granted, this works best with pairs of files, so I did a quick check in microsoft/vscode and found many couples of similarly named files (some *.ts and *.test.ts, some *.ts and *.css), where it's a natural pattern to go from one to the other. There are also groups of three, but many fewer. Where my proposal may not help as much with these groups, neither does the current implementation.

The savings show that it's wrong to return the current editor as the first result after search, as the editor does now. (If you've commented on this assertion, I must have missed it.)

The temporary cost of the switched order in other situations shows up mostly where the slow cognitive process of recognition and list navigation outweighs it.

As you wrote, coming back to two files in two editor groups could also be quite common, yes. The default themes don't make it quickly obvious which side is active, that's an unrelated bug. (My own theme doesn't have this bug.) If somebody reached for quickFind in this situation, with the current implementation the list would have the active editor first, and the other editor somewhere down the list (not necessarily the second because the user may have more recently been in other editors in the active group). The user must use recognition to find the right thing in the list.

I would see no problem at all with restricting my proposed switch of the first two results only after a search query has been typed.

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!