Search: target particular set of files

[alvenchen]

• VSCode Version: Code 1.9.1 (f9d0c687ff2ea7aabd85fb9a43129117c0ecf519, 2017-02-08T23:31:51.320Z)
• OS Version: Darwin x64 15.6.0
• Extensions:

Extension	Author	Version
cpptools	ms-vscode	0.10.1

---

Steps to Reproduce:

1.when i use global search, it's not easy to type whole file path and name in input box, hope that there is a convenient way to use highlight in search current file by typing ""

---

Note from @roblourens This includes searching in any particular subset of files such as

• All open files
• Files staged in git
• Recently modified files

etc

[edespong]

I have created two branches on my fork, the first one Support for tokens expanding to search patterns contains basic support for @mromanch idea of pre-defined filters. This branch is independent of the blocking API issue, and if @roblourens thinks it is a good idea, I could create a new issue to which a PR can be submitted.

The second one (Experimental) support for targeting sets of files builds on the first one, but adds support for editor (open, unsaved files etc.) and git (modified, untracked, etc). The code contains a very ugly workaround to the #48958 issue.

[gjsjohnmurray]

Maybe this could leverage the new Search Editor that landed as a preview in 1.41. Then we could have a way of re-searching (with a different search string) in the exact set of files that an initial search found its matches in.

cc @JacksonKearl

[JacksonKearl]

@gjsjohnmurray for the time being, an extension could pretty easily contribute such a command. I can fill in with more details if anyone is interested.

[bdrazen]

Would love a way to limit search to only changed/modified files.

[electrovir]

@JacksonKearl do you know of one that already does this?

[JacksonKearl]

@electrovir No I don't know of any extensions building off of the Search Editor. This is probably a good thing for now, as it is still experimental and subject to change.

Edit: I take back what I said about this being about an extension being able to do this, I think the right way to do it would be adding a selector syntax to the search includes/exclude patterns (@opened and @modified, maybe?), that would be able to be used across all search clients.

[dnecklesportfolio]

This would be so helpful, im on a project right now and I am surprised this hasnt been added with the lengthy discussion had so far.

[dnecklesportfolio]

workaround, i search in every file manually.. which is tedious but once you do it once, go to each file and search.. each file comes up in the results on the right.. and then you have the feature we've been desiring

[eminozlem]

yea good workaround let me just open 56 files and search every single one of them XD

Dwayne Neckles notifications@github.com, 22 Oca 2020 Çar, 23:26 tarihinde şunu yazdı:

workaround, i search in every file manually.. which is tedious but once you do it once, go to each file and search.. each file comes up in the results on the right.. and then you have the feature we've been desiring

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/20530?email_source=notifications&email_token=AAD36PCTPQI3PMFLDKC43MTQ7CTV3A5CNFSM4C73QHN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJU7O5I#issuecomment-577369973, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD36PG43RLOPADFNMSR57TQ7CTV3ANCNFSM4C73QHNQ .

[dnecklesportfolio]

Ha Good point.. I meant it workaround for if you have a few files under 10.. Hope Vscode considers this.

[Sadi58]

Two popular workarounds: 😉 https://kate-editor.org https://notepadqq.com

[DavidMulder0]

Btw, for those who want to search in their (staged git) changes, you can use

git diff-index -U --cached -G <regexp> HEAD

Sadly as it's a diff command technically, it will include the a and b in the paths, so ctrl+click won't work from the integrated terminal 😢

[codenem]

Btw, for those who want to search in their (staged git) changes, you can use

git diff-index -U --cached -G <regexp> HEAD

Sadly as it's a diff command technically, it will include the a and b in the paths, so ctrl+click won't work from the integrated terminal 😢

To search in git modified/staged files only, I copy the git status file names in the result (all at once), then paste them in the editor and manipulate all lines at once to get a unique line with all file names joined by a comma*. I then copy this line in the "files to include" of VScode, and thus can search in only the modified/staged subset of files.

*On mac OS VSCode, Cmd+A to select all, then Opt+I to get a cursor at the end of each line. Then just add a comma on each and press Del. You get one line with all file names joined by a comma. You can also add a prefix like /Users/<your_user_name>/path/to/project/ all at once if needed

[VishmayShah]

"file to include" may actually work if you can enhance the search and context menu on the page. Somewhat like this

Where

1. Multiple files can be included.
2. The full path is used, so other pages having the same file name doesn't get affected(child, sibling or parent)

Or Advance: two options:

1. Include this page in search
2. Include all pages in search

Share your thoughts!

[krishna81m]

Two years and no update or a plugin, I end up using a work around to use specific folder for all of my notes and only search that folder in a dedicated window to limit search results

[JacksonKearl]

@krishna81m you can search in a specific folder by putting it in the “files to include” box. This is about targeting files that can’t be classified using globs.

[dnecklesportfolio]

Dont feel too bad vscode users, sublime, atom, and brackets do not appear to do this either.

[gesslar]

Dont feel too bad vscode users, sublime, atom, and brackets do not appear to do this either.

I switched from UltraEdit, which has this, to VS Code. It's the only feature I'm still missing.

[evenfrost]

@dnecklesportfolio FWIW, Sublime had this feature from long ago. You can search in e.g. currently opened editors with <open files> placeholder.

[krishna81m]

@JacksonKearl , apologies for not being clear, I only want to search in files "that are open" and didn't there was a way to do this yet.

[VishmayShah]

My current workaround for this functionality is notepad++. Still looking forward to this.

[kotpal]

Will this feature ever be considered for VSCode?

[JacksonKearl]

I see the appeal to having something like sublime's <open files>. Still not clear what other custom sets would be allowed. Ideas: tracked, staged, modified, etc. But those would need to also work across scm providers, so there are some things to consider about how that works.

Also not sure what the UX would be for inputting them. We have custom flags in the extension search and settings search identified by @, but those searches are both somewhat constrained in terms of what you might search for. In the workspace search however you should still be able to search in the literal file <open files>.txt or foo/@open, etc.

[kotpal]

Let's start with 'Search in Open Files' at the very least. That seems to be the most requested feature.

We can't work on all the features - like integration with scm, searching different artifacts and such - right off the back.

[JacksonKearl]

@roblourens any thoughts on how a syntax for these might look? If its opt-in I think @open/etc. would work well, but we'd also need some escape mechanism. (@@?)

[roblourens]

There is already an open PR that partly implements this with @ but it's blocked on needing fixes in search API

[VipSaran]

Cmon, it's ridiculous. The search looks in open files by default only if the file was focused after it was opened!

We need an option to automatically look in all opened files (in the window).

[kglickman]

I would love a recently used list for the "files to include". I am constantly toggling back and forth between a few different directories.

[JacksonKearl]

@kglickman you can use the arrow keys to scroll through your history, does that help?

[kglickman]

Yes, it definitely does! It would be nice if there was some kind of visual indicator that you could do this ...

[carehart]

Going back to the original post and the few that followed, which were focused on how to search "only open files", I'll share something I just discovered.

If you have only opened files in vscode directly, by way of using File>Open, or Open Recent, or by opening a file from the OS into vscode, etc., THEN a search/find in files WILL indeed search ONLY (and all of) those opened files.

But it's if you use File>Open Folder, that's when things change about search (and of course many other ways about the UI). It THEN presumes to search first all files/folders in THAT folder, and you can't tell it to ONLY search open files. To be clear, it DOES ALSO search open files--and it shows the results of that as "other files", below the search of the "opened folder".

I suspect it's those folks (who use that valuable "open folder" feature) who are calling for an option to be able to limit the search to ONLY open files. I didn't see it mentioned in any comments above, so I wanted to offer this distinction.

I share it also for those coming from other editors, who may tend to only work in a few files, perhaps spread over multiple folders, and they may want to by default have it search THOSE (and only those) open files. In that case, just close the "open folder" feature (File>Close Folder), and then the search will indeed be only for files you open otherwise.

All that said, I can see why folks are STILL waiting for an option to tell it to search ONLY open files, for when they DO have reason to have used the Open Folder feature.

Hope that's helpful.

[eminozlem]

This is never going to happen is it

Charlie Arehart notifications@github.com, 15 May 2020 Cum, 20:57 tarihinde şunu yazdı:

Going back to the original post and the few that followed, which were focused on how to search "only open files", I'll share something I just discovered.

If you have only opened files in vscode directly, by way of using File>Open, or Open Recent, or by opening a file from the OS into vscode, etc., THEN a search/find in files WILL indeed search ONLY (and all of) those opened files.

But it's if you use File>Open Folder, that's when things change about search (and of course many other ways about the UI). It THEN presumes to search first all files/folders in THAT folder, and you can't tell it to ONLY search open files. To be clear, it DOES ALSO search open files--and it shows the results of that as "other files", below the search of the "opened folder".

I suspect it's those folks (who use that valuable "open folder" feature) who are calling for an option to be able to limit the search to ONLY open files. I didn't see it mentioned in any comments above, so I wanted to offer this distinction.

I share it also for those coming from other editors, who may tend to only work in a few files, perhaps spread over multiple folders, and they may want to by default have it search THOSE (and only those) open files. In that case, just close the "open folder" feature (File>Close Folder), and then the search will indeed be only for files you open otherwise.

All that said, I can see why folks are STILL waiting for an option to tell it to search ONLY open files, for when they DO have reason to have used the Open Folder feature.

Hope that's helpful.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/20530#issuecomment-629398063, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD36PG44ZEZB3PVEX255E3RRV67BANCNFSM4C73QHNQ .

[fadimounir]

@roblourens Any updates on this? Would love to have this feature

[narkoze]

Waiting for this 😇

[jockrow]

could be some like this:

[JacksonKearl]

@jockrow you can do that already like so:

[markdomansky]

Commenting only to add endorse that we need this feature.

[eminozlem]

yea its not happening XD Still suplementing Notepad++ literally just for this

[EwSt]

How is this not a thing? Also why doesn't the "files to include" have a better way to display all files i put it in it?

[jackmparker]

Commenting to add support for a "search open files only" feature.

[jkozera]

@gitnix you seemed to have the same idea as me :)

@yuval-gilboa That would be great. In addition to the fields you have listed, I would imagine custom search scopes (where user defines exclude/include files) also being available. "tests", for example, would be a good custom scope. I have a separate issue opened for custom search scopes #42350.

Like here?

I'm not sure if such quick PoC hacks are a good idea, but maybe a proof of concept would encourage someone to do a proper implementation. Anyway, there it is:

https://gist.github.com/jkozera/f3bbfdbeb1ffdcc08ef7a02acdfc625b

Note it may be unsafe (it downloads jQuery JS), or may break with different VSCode versions if HTML class names change, for instance. The checkbox also may disappear when navigating to some other places in the GUI.

Anyway pasting it in devtools (Help -> Toggle Developer Tools) while the exclude input is visible worked for me.

[machineghost]

Came here to also beg for this feature, only to discover JacksonKearl just picked it up. Thank you! Here's hoping we finally see this super-useful feature in VS Code! 🤞

[eminozlem]

So, is this happening or no ?

[JacksonKearl]

Small update on what I've been considering about this feature:

We're interested in this feature, but unfortunately it isn't a priority right now (clearly 😉). I have however been thinking through potential designs for it. I think a good model is an extension search/settings editor styled UX with a CompletionItemProvider styled API:

extension search's @ completions:

an API like:

type SearchGlob = {
    id: string,
    label: string,
    description: string,
    details?: string,
    patterns?: GlobPattern[]
};

export interface SearchGlobProvider<T extends SearchGlob = SearchGlob> {
    provideSearchGlobs(token: CancellationToken): ProviderResult<T[]>;
    resolveSearchGlob?(item: T, token: CancellationToken): ProviderResult<T & { patterns: GlobPattern[] }>;
}

export namespace window {
    export function registerSearchGlobProvider(provider: SearchGlobProvider): Disposable;
}

In this model, I would expect core to contribute some selectors like @open, and extensions like the builtin git extension to provide @git.Dirty or similar. Further, something like the C# extension could provide a @csproj:MyProject or @csharp:tests.

This is very much not a final draft, and there are still a lot of open questions worth considering...

• Should selectors support "arguments"? (i.e. does every possible selector need to be provided by the extension, or. should they accept user input? Things like @lastModified:<1w could be interesting).
• Should we natively support configuring these in user/workspace settings?
• Should we require/support extensions statically declaring their selectors? (This would mean we don't need to wait for every selector-providing extension to activate in order to show selectors, but it also limits the ability to operate dynamically)

If anyone reading this has any input regarding any of the above or potentially other open questions I'd love to hear!

[edespong]

@JacksonKearl Yes, it will be very powerful if they can support extension-specified arguments.

In my branch (Experimental) support for targeting sets of files , the approach taken was to use a syntax like @git(modified, arg1, arg2), or @editor(open). These would typically not be used direct, but in conjunction with the pull request Support for tokens expanding to search patterns , which would allow extensions to specify aliases for these, e.g. @openSrc <- [@editor(open), '**/src/'] which would expand to search in open source files.

Any syntax that would support multiple arguments would be fine, I think.

[eminozlem]

I dont know why people keep suggesting complicated or unrelated 'solution's. What we need is so simple "search in open(ed) files". So If I have "inc/header.php" and "assets/style.css" open in my workspace, I want to search only in these 2 files. Nothing more, nothing less.

Dreamweaver had this since 12 years. VSCode is fairly new, but has to pick up the pace, soon its gonna be 4 years since this has been requested.

[edespong]

I dont know why ...

It is literally described in the title of the issue and the initiating post

[oholimoli]

Please add this basic feature

[machineghost]

@JacksonKearl I truly think you're letting "perfect be the enemy of the good" here ... and it's preventing all VS Code users from getting a really valuable feature.

I don't think everyone in this thread needs the worlds most complex file filter. Please don't get me wrong: I would imagine that everyone who saw your beautiful mock-up thought "that looks awesome!" (I certainly did) ... but it's also crazy scope creep.

It seems to me a very significant chunk of the people in this thread just need a "find across open files" feature. All this "perfect dream UI for filtering by any type of file" stuff is is making it impossible to provide that extremely basic feature (which, as others have noted, is a feature that exists in far less powerful editors).

If we could reduce or split this ticket to just be "add a checkbox to find in open files" ... it's not that I don't want your beautiful, and far more powerful UI ... it's just that I don't want to wait for it while it holds up the much more utilitarian (and FAR EASIER TO DELIVER) feature that so many users need.

I can't speak for anyone but myself, I truly think a large number of others would similarly appreciate a working simple feature we can use now, over a big complex one that won't arrive until 2030.

[JacksonKearl]

@machineghost thanks for the feedback!

I definitely agree that small, incremental, work towards the "grand vision" is better than an all-or-nothing approach.

That being said, I think it's important for the work to actually be incremental, so perhaps instead of adding a single-purpose checkbox to the UI for opened files (with all the UI discussion that entails...), a set of @-filters could be implemented in core (potentially starting out with just @open), deferring discussion of API and extensions contributing filters.