Vscode: 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

[roblourens]

Sorry @alvenchen, I don't quite understand what you're asking for

[alvenchen]

@roblourens Thanks for reply.I wonder is there any convenient way to use global search when searching "current file" or "all open file".

[roblourens]

Expanding this to cover searching open files or searching git modified files, or some other class of files.

Edit - Does github not show title edits in the history anymore?

[yuval-gilboa]

I would also request that you define separate command for starting a search in each search scope, so i can map separate keyboard shortcuts for searching in the different scopes (current file, current folder, open files, all files, etc.). If we have that, it would suffice to cover the use case i requested in #40523, which you've closed.

[yuval-gilboa]

Any word on this? I don't see much progress for this feature request.

To clarify, we're looking for something like this:

Kind of dropdown menu that allows you to select the search scope in the search panel. Possible search scopes can be:

In addition, expose a command for each search scope to allow initiating a search in that scope quickly through keyboard shortcut.

[gitnix]

@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.

[atif089]

Friendly bump, I'd love to have this. Thank you!

[ckelley7]

This is necessary as I use it all the time in VS.NET

[malfusion]

@roblourens Do you think limiting the scope of the "files to include" field, to the current files/files would be enough to accomplish this? I already have a version of VSCode where i have modified it to do this. I can submit a PR soon if you think that's enough.

[roblourens]

I don't understand, so if you type in "files to include", it would only search using that pattern in open fils?

[atif089]

@malfusion I like the idea, but wouldn't that discard all the unsaved changes in the editor? (also slower because of i/o)

[malfusion]

@roblourens so the "files to include" is a glob pattern that is searched. So the trick here would be to find the files that are required, generate the glob pattern and then update the "files to include" field with it. And the search would only search the matching files.

@atif089 if the question meant "would the search disregard the current file's unsaved changes", then I'm not sure yet. I'll have to check. But to my knowledge, the search is performed directly on the file system, so only saved changes might be searched.

[bkarlson]

was amazed (in bad sense of this word) to discover VSCode cannot do it... it's 2018 after all, seems to be a common sense feature present in any other code editor or IDE.. bumping the issue to attract attention to it.

[damienleroux]

+1

[e105-gamma]

+1

[yuval-gilboa]

@roblourens

Any update on this? This feature request has been open for a year and a half. I don't see any update regarding this feature for a long time, nor do I have any visibility on your future plans regarding this.

[orecht]

I used "search in open files" a lot in Notepad++. It is especially useful for searching multiple csv files (or other data files).

[rdewolff]

Love this feature!

[shahidmau]

+1 must have feature.

[Instagit]

How about changing the scope of "files to include" with key words like @open, @closed, @modified, @unsaved?

It wouldn't require any UI changes and is easily extendable, so if in the future you decide to make files searchable by modify date, that could be @modified(2d) or @modified(48h) for files that have been modified within the last two days.

I can see this being a very useful advanced feature without needlessly cluttering the UI.

[BillDenton]

From #18796 :
"Request ability to search only in the files that are loaded in the editor. In addition it would be good to have a search results window for find (in current file Ctrl+F) so that you can see a list of matches with some context and the ability to copy the search results and click on them to go to the match. This should also work with replace. May be there should be another window like Output, Problems, etc. Ideally this would be able store multiple sets of search results in multiple windows. See SlickEdit for example."
I think the ideas have cover most of #18796, but possibly not suggestion of multiple search result windows. It very useful to have multiple search results, particularly when working with log files.

[roblourens]

I think https://github.com/Microsoft/vscode/issues/16488 might cover the rest of that, keeping track of multiple independent searches

[mromanch]

I really love the suggestion from @Instagit!!!

I find it superior to just a UI dropdown, because I can type something like @modified, @open, src/**/*.xml into either the files to include or the files to exclude and anything else that takes file filters could accept the same patterns.

I also love how the idea includes the ability of extensions that extend the filter functionality. (_Dreaming_ :sleeping::heart_eyes::joy::stuck_out_tongue_winking_eye: _of GitLens support for @git(52b15e9) allowing me to search within a specific commit._)

Not to mention, if you can accept pre-defined filters, than it's not hard for me to imagine user-defined filters, e.g.:

"search.filter": [
    { "config": ["**/*.config", "src/**/*.cscfg"] },
    { "deploy": ["**/deploy", "@config" },
    { "test": ["**/test", "!**/test/log", "!**/test/out"] },
    { "modified": ["@staged", "@unstaged", "@untracked"] },
    { "unmodified": ["!@modified"] },
    { "src": ["!@deploy", "!@test", "@modified"] },
    { "prod": ["@src", "@deploy", "!@modified"] }
]

Some things to note about the above suggested syntax:

• filters are an array of patterns
• filters can be defined from filters
• filters support _gitignore_ syntax including negation (i.e. same as existing filter fields)
• filter pattern order matters , e.g.:
  
  
  
  • the @src filter includes @modified files that might be excluded by !@deploy or !@test
  
  
  • the @prod filter includes @deploy back in, but removes @modifed
  
  

Given the above syntax, the builtin filters only need to support some basic operations like @open and @unsaved. Then @closed simply becomes !@open.

I'm not sure if @folder, @workspace and @project make sense. In the find panel, anything like @folder, or even a UI dropdown will lack context. However, a keybinding for something like find(@folder) probably does make sense.

I feel like minimum Git support is important. Filters for @staged, @unstaged, @untracked and default definitions for "modified": ["@staged", "@unstaged", "@untracked"] and "unmodified": ["!@modified"] would be really nice. I don't know if these are things that must happen in this feature, or just things that must be enabled and support gets left to an extension.

[roblourens]

The custom filters are a really interesting idea.

We recently added intellisense to the extension viewlet and settings search input, could do the same here.

[imnickvaughn]

+1 search open OR git modified files would be used constantly

[haugerbr]

I specifically would like to see at least a current file and all open files option. It doesn't seem like this would be hard to implement. What files would I be looking at in vscode if I wanted to implement this and submit a pull request?

[IvanPizhenko]

+1 for this feature. Especially would like to have "all open files" and "modified files"

[IvanPizhenko]

Any plans to implement this in 2019?

[thisisrachelramos]

+1 all open files search option would be great!

[deepaktatineni]

Any plans to includes this feature?

[edespong]

I will be taking a stab at this based on the ideas of @Instagit and @mromanch

[roblourens]

Sure. Just please discuss your approach with me before spending a lot of time on it.

[edespong]

Basic approach
The approach I have looked at is to extend the QueryBuilder to make use of a new 'token expansion' class. The current builder splits the query into glob patterns and makes IExpressions out of them. The idea would be do the expansion between the split and conversion to IExpression. For example, the include pattern *.ts, @open, *.css would leave the *.ts and *.css intact while expanding @open into the file paths of the currently open files (though issue https://github.com/Microsoft/vscode/issues/48958 is blocking for this to work).

Tokens that simply expand into normal globs can also be supported via config.

Extension
The actual token expansion will not have any hard-coded tokens, but these would rather be supplied by config and extensions. The ones I have looked at are the editor and git, to support for example open and unsaved files (editor) and changed, staged, etc (git). The extensions esentially use the command framework and the token expander use the ICommandService to call the extension and get the expanded token back.

Syntax
The default @ syntax for vscode seems to be @token:parmater, e.g. @editor:unsaved. This can then be shortened or aliased for the most common use-cases, see Configuration.

One question would be how to handle use-cases where multiple parameters are needed and what the delimiter should be. E.g. searching for files changed within the last day. Like @file:modified;24h or @file(modified, 24h).

Configuration
Pretty much follows @mromanch idea. Can either define hard-coded globs, combinations of previously defined configuration or reference tokens defined by extensions. Example:

{
    '@config': ['**/*.config', 'src/**/*.cscfg'],
    '@deploy': ['**/deploy', '@config'],
    '@modified': ['@git:changes, @git:staged, @git:untracked']
}

UI
Right now, there is only 'files to include', but other programs like Visual Studio also has a 'scope' (e.g. Entire Solution, Open Files, etc). Does it make sense to differentiate between them or will it only be confusing?

Auto-completion?
Have not looked into this.

[roblourens]

This sounds great, however it sounds like https://github.com/Microsoft/vscode/issues/48958 will be blocking most of this. Unfortunately that's harder to fix than it sounds because it will involve changing extension API and I will need to drive that.

[edespong]

Yes, I do not see any good way of solving this issue without having https://github.com/Microsoft/vscode/issues/48958 in place. I will keep an eye on if/when it is fixed.

[adjenks]

https://stackoverflow.com/questions/42011289/how-to-search-only-in-currently-open-files-in-vscode
https://stackoverflow.com/questions/56086094/how-do-you-search-within-all-open-files-in-visual-studio-code-not-in-a-folder

[eminozlem]

bump . i really need this, this could be the only reason if I ever go back to Dreamweaver. "Search in open files" is very handy 😄

[abhay-gooru]

that is really a blocker, i came from sublime to vscode, before that notepad ++, vs.net etc all have them, but vscode does not. I have already going back to sublime or searching another alternatives. Soon i find that will dump VS code

[Bagnall]

Support request for "search in open tabs". Please!

[SuperV1234]

+1 for search (and replace) in open files, it is extremely needed.

[gino8080]

bump! +1

[FabianLauer]

Guys, please stop "bumping". It triggers notifications for everyone involved in the thread and doesn't add any value. Just hit 👍 in the top comment instead.

[carehart]

One problem with hitting the thumbs up in the top comment is that that top comment (the issue title itself) doesn't convey what nearly all the rest of the comments are getting at: a desire to have a feature to "find in open files/tabs". The OP worded the issue title and even their initial post in a way that does not convey this broader problem. I wish we could more clearly be voting for this broader problem/feature request.

Is anyone (who is a party to this thread) aware of any other issue or PR where attention to this broader issue (a desire to find against open files/tabs) maybe has moved? so that we can drive our support there, more clearly?

[roblourens]

@carehart I consider this to cover that request, and I added a note to the OP to clarify that.

[carehart]

Great. Thanks.

/charlie

[eminozlem]

Yea I am looking forward to this. Every time this thread gets replied I get
excited, only to find out it was yet another bump

stderr-to-devnull [e-mail], 25 Eyl 2019 Çar, 14:34
tarihinde şunu yazdı:

So this has been open for 2 1/2 years, is it so monumentally difficult to
implement? Other more basic editor already have this (Notepad++ for
example). I need to be able to search in all open file tabs. How many thumb
ups are necessary? Maybe I can talk with my family and friends to create
accounts and support this request.

—
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=AAD36PFLHJXMWKYQMTIKZN3QLNEC3A5CNFSM4C73QHN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7RSDEQ#issuecomment-534978962,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD36PFHHBZXEBOGNZ7XJL3QLNEC3ANCNFSM4C73QHNQ
.

[aetonsi]

Hi,
i found out that i can "search only in open files" by using a backslash instead of a forward slash.
Is it a feature? Is it a bug? (if it's a bug i'll open an issue, obv)
Demonstration screenshot attached (i was looking for php files inside the "backend/app" folder)

VSCode-win32-x64-1.38.1, extensions disabled, exclude settings/ignore files disabled

[francoismassart]

Hi @aetonsi, I just tested this technique on VS Code on macOS and it does NOT work 👎

Here is my config...

Version : 1.38.1
Validation : b37e54c98e1a74ba89e03073e5a3761284e3ffb0
Date : 2019-09-11T13:31:32.854Z
Électron : 4.2.10
Chrome : 69.0.3497.128
Node.js : 10.11.0
V8 : 6.9.427.31-electron.0
OS : Darwin x64 16.7.0

Cheers

[robert1826]

I've found a simple solution but it might not work for all scenarios.

scenario: search for a keyword in modified files between two branches (like master and current branch) - I'm using gitlens (kinda solves #82756)
steps:

1. compare the two branches in gitlens to find the modified files in the compare section
2. right click on 'x files changed' and click open files
3. to to explorer in vscode
4. select the open all files under open editors section
5. right click on the selected files and click copy path (or relative path)
6. open an new untitled file and paste the paths and then proceed to join all the paths by commas
7. open search all files and paste the comma joined paths in the files to be searched section

this idea could somehow extend on multiple levels but as you can see it's not the best and I'm definitely waiting for an official solution from the vscode team

[jesseko]

Sublime has a nice model for this that could work for VSCode too.

The text input for which files to search in is paired with a "..." control to get access to these special options. When one is selected, they insert a special entry into the text field. This lets these be used along side other search patterns and makes it easy to always see the full set of active search patterns in one place.

Dropdown at right

Choose "Add Open Files"

<open files> is added to the text field

You can have multiple of these together, and it's easy to delete them at any time

[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 [e-mail], 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 😢

[nemile]

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 [e-mail], 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.

[machineghost]

If that delays things further, I think you're still letting perfect be the enemy of the good. But if it's possible to get people the functionality they need now, AND do it with @ - filters ... AWESOME!

I'm just trying to point out that every time you delay the extremely basic feature VS Code should have had years ago, you make your users' experience worse ... even if you do it out of a desire to give users a really great and much better feature someday.

TLDR; The YAGNI principle applied to this ticket months ago.

[planetwarevince]

+1 for an option to make search [and replace] act only on "all open files".

[JacksonKearl]

Created https://github.com/microsoft/vscode/issues/106790 to track exploring how to implement this for just opened editors at first.

[ArturoDent]

It was recently reported in a SO answer that using ./ in the files to exclude accomplishes searching only in opened files? Please test this. Seems to work for me but I wonder if there are cases where it fails. So it basically excludes all files, but vscode will nevertheless search in files that are currently open. Could it really be this easy?

See https://stackoverflow.com/a/64535262/836330

[penguin020]

Work Around:
Entering "./" in "Files to Exclude" forces VSCode to return only open files.

https://stackoverflow.com/questions/42011289/how-to-search-only-in-currently-open-files-in-vscode

[machineghost]

So, again, literally all that's needed here is a checkbox in the UI: every last bit of functionality already exists.

The only thing preventing millions of VS Code users from being able to search across open files (something they can already do in many major text editors) is the fact that they have to come find this issue to learn how. Adding a simple checkbox to the UI would solve this (as would a bit of explanatory text in the CTRL + SHIFT + F pane, a single @ filter, or likely any number of other solutions).

My point being, the solution isn't the hard part here: getting the VS Code maintainers to believe a solution is needed, and shouldn't have to wait for the worlds most perfect filtering system to be finished first, is.

[roblourens]

There are hundreds of open feature requests that would be resolved with "just a checkbox", then where does that leave the UI? And @penguin020's workaround I don't think will really work in all cases.

[JacksonKearl]

The problem is that Open Editors searching in general only works on editors that have been viewed this session. If you reload and try the workaround you'll see no results. As it stands that's an unfortunate limitation but overall fine, however if we are to ship a feature that is called "search in open editors", it should work with all open editors, not just the ones that have been clicked on since reload.