Change:
} } <del> private _getPicksFromMatches(matches: FileMatch[], limit: number): (IPickerQuickAccessSeparator | ITextSearchQuickAccessItem)[] { matches = matches.sort(searchComparer); </del> <ins> private _getPicksFromMatches(matches: FileMatch[], limit: number, firstFile?: URI): (IPickerQuickAccessSeparator | ITextSearchQuickAccessItem)[] { matches = matches.sort((a, b) => { if (firstFile) { if (firstFile === a.resource) { return -1; } else if (firstFile === b.resource) { return 1; } } return searchComparer(a, b, this.configuration.sortOrder); }); </ins> const files = matches.length > limit ? matches.slice(0, limit) : matches; const picks: Array<ITextSearchQuickAccessItem | IPickerQuickAccessSeparator> = [];

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --I find quick search great! So good I though it could be great even when the search is limited to the current file. Right now there is no simple menu to see all matches of a searched string in the current file, which commonly available in other IDE e.g. notepad++: ! So instead of having to use workspace search + tweak/filter results, it'd be nice to just use the quick seach but limited to the current file. Following the same philosophy as with other quick menus: tiny modal in the middle etc. Note: the filename section divider would be not needed. And for being able to seach the selected text like in both regular find/search I opened This is also in-line with quick symbol seach which has it for editor/workspace. I guess for quick search in editor I would use . ! Best regards!
Any reason not to use the normal Find in file which is easily accessible with cmd/ctrl+f? <img width="611" alt="image" src=""
With the normal "Find in file" widget you can see the amount of hits, get highlights in the editor/scroll-bars, and navigate to next/prev. What I am proposing is reusing the quick search window as a mean to see all the hits together with a bit of context + quicker navigation between them. Just like it does for all the files but limited to the current opened one. Maybe quick search could put the current file first, but seems simpler to have a separate view just for the file. With the GIF I was using notepad++ "Find all in current file"/"Find all in opened file" as an example, the former shows a summary of matches in the current file only. So basically the program offers the feature on top of its "Find in file" highlighting etc.
The current file results do already come first in Quick Search if there are results in that file. Anyway, I'll pass this over to who owns Quick Search as this seems like a feature request for that... but like I said, I feel like there's already a Find in File experience that is easily accessible and scopes to the current file.

Now, if you want to see the total hits in each file in Quick Search, that's doable but a separate feature request.
That was not my experience, it seems inconistent. I'm at the last public regular version: 1.88.0 (system setup) Maybe it has to do with file history/recent files? Is it already handled in the last? An example: ! Nonetheless, if you open the query empty and start typing it will probably jump between files anyway. There is nothing wrong "Find in File". This FR was to provide an idea for another quicksearch query on top of it. Basically it seemed simple in scope but yet IMO quite useful: fast and visually see all results in the nice quicksearch view + follows the same phylosophy as other quicksearch query strings for editor/workspace.
Currently, it just lists the open files first, but we could do a small tweak to make the active file first! Do you think that that would help with your use case?
Yeah, it would definitely help :) As I mentioned, that would prevent the quicksearch from jumping to other files when searching for a selected text in the current file. It would be basically the same as a dedicated search for the active file, but with more info beneath, so ok. But one thing to mention: when you open an empty search and start typing, the editor starts switching between files to whatever partial string matches. I guess the current "active" editor is kept until you press enter so it can adjust, but preventing this fast switching of files was also what I had in mind with simply limiting the quicksearch to the active file.
I'm not too sure what you're referring to with this. Do you mean that the shifting that happens while it's loading is too jarring?
Not really. Sorry I tried to explain myself too quickly and was partially wrong I was referring to how the editor would jump temporally to other files while you type if the string is not in the current file (nothing to do with partial substring matches as those should hit the active file too). In this case a limited quicksearch to the current active would simply show an empty list, which is informative in itself.
I made the change in On tomorrow's insiders, you can verify it works: quick search for something in the active editor.

results for the active editor should appear first if they are available, and it should stay like this as other results load.