Investigate predefined file filters search

[JacksonKearl]

In #20530 we've discussed custom file sets for search, and in the process the originally simple ask for a way to search in opened editors evolved into a large scale feature request involving extension contribution APIs, new UX, and updates to the search UI.

This issue tracks scaling that back to just searching in opened editors in order to more quickly experiment with various ways of implementing the general feature.

There are two primary proposals for how this might look:

1. "Universe" Dropdown. This is what products like Dreamweaver use, where a dropdown contains a collection of "universes" of files to search:
   

In this case, the dropdown would configure the "universe" of files to search, and the include and exclude filters would further narrow down files within that universe.

In this model, one could search things like "all opened editors with .ts extension", but not things like "all opened editors and additionally all files in workspace with .ts extension" or "all opened editors and all test files" (assuming in the future extensions can contribute items)

2. Custom Include/Exclude Globs. This is what products like Sublime use:
   
   (Note sublime surfaces these globs via a dropdown, but this is not the "universe" UX of above)
   And would likely be surfaced through @ blobs similar to the extension search:
   

In this case, each of these globs are entered directly into the include/exclude inputs, and they expand to some set of files/globs at searchtime.

In this model, one could search things like "all opened editors and additionally all files in workspace with .ts extension" and "all opened editors and also all test files", but not things like "all opened editors with .ts extension".

One note of consideration with this approach is that we sill would need to support searching in a directory literally named "@open", so some means of escaping or disabling the expansions is required. This could be done with a "use @ expansions" toggle in the include input, similar to the existing "use global ignores" toggle in the exclude input:

Open questions:

1. Which model is more important to support? "This universe of files, filtered with these include/excludes", or "include/exclude this meta-glob in addition to the rest of my globs"? IMO the first seems more helpful, but I could be convinced either way.
2. Do these UI's necessarily force the above models?

[machineghost]

Stupid question: why such complex UI? As you yourself wrote:

This issue tracks scaling that back to just searching in opened editors

So ... aren't we just talking about a boolean/checkbox for: "search in open files" (or don't)?

It feels like this scope creep on the UI is going to make this unnecessarily harder to implement.

[IvanPizhenko]

I'd not say UI is complex. Last picture shows existing UI, and it sounds like just need to support that special glob

[JacksonKearl]

@machineghost

One important question outlined above is how does that combine with include/exclude filters? Please read through the issue body to see the options.

Also, how can it be extended to work with the other potential groups of files users might want to search within (modified, staged, etc.)? I'm not interested in a one-off solution to the single question of how to search in open editors. I understand that that's all you're interested in, but there are many many many other users, and they have other priorities.

[planetwarevince]

I suggest the "boolean checkbox" model would override/ignore the include/exclude filters and literally only look at the opened files. If I want to act on all the open files and only the open files, I'm not interested in the filters.
Can someone demonstrate a use case where the filters matter if acting on all open files? (In my use case it's convenient enough to close anything I want to exclude from the "all open files" filter)
Thanks, @JacksonKearl!

[machineghost]

@planetwarevince hit the nail on the head!

@JacksonKearl I understand you don't want "one-off" solutions, but solving problems no one has isn't a good use of anyone's time.

It's not just me: there are a large number of users who want "search within open files", and you can see as much simply by looking at the thumbs up and comments in the original issue. But again, if you look at that issue, it's clear that the group of people who want anything else is much smaller.

To be fair, you will see comments for "everything and the kitchen sink" upvoted ... because if you say, "do you want features?", of course devs will say "yes we do" :) But if you actually look at the problems people are having, the clear majority are "I can't search through open files." And in all of those comments, I didn't see a single person say "I want to wait a long time for a solution" ... which is what you are de facto saying when you let scope creep happen.

The entire way this issue got made was because of scope creep in the original ticket. But look, even if it wasn't ... understanding "YAGNI" is important for any software project. If you don't know a clear user need, you shouldn't try and solve it. Or if the need for a feature is weak (it only affects a small number of users), and you don't have the capacity to help them, you shouldn't try and solve it.

Here you do have a clear user need for "search within open files". Hopefully you also have the capacity to serve that need, by adding a checkbox. Anything else unless there is evidence of a clear/strong user need ... seems like the definition of YAGNI to me: it's still making perfect the enemy of the good.

So I guess what I'm trying to say is, please don't confuse "I'd like to have a feature, if you're offering" upvotes for a reason to delay a solution to a real problem people have.

[JacksonKearl]

People have wanted search in git modified (and some other sets) for as long as they've wanted search in open. Just because you haven't been around to see the "clear/strong user need" doesn't mean it doesn't exist:
#36345
#38965
#39484
#82756
#88704
#94941
#101481

All of the above were pointed to #20530, and the upvotes on #20530 are representative of all of those issues and the users who were funneled to it via those issues.

[planetwarevince]

I understand. This issue is far larger than my simple use case.
At this point I'd be happy with either of the models you've proposed, Jackson. Thanks for tackling it!

[IvanPizhenko]

Finally, "the ice has started to move on", and we hopefully will have exciting new feature in the nearest months, which will let us search in the opened, staged, changed, unchanged, whatever else file sets.

[machineghost]

Well, if you actually plan to address those issues ... great! I just don't want to see what happened to the last ticket happen to this one.

[eminozlem]

finally, nice

[p487morgan]

Please get something out there...

'Find in Open Files...' is such BASIC functionality and almost EVERY user will benefit.
The other stuff is clearly very important to some people... but its not an EXPECTED feature.

One could work around the other stuff - briefly use another editor to do the search, then come back to vscode.
I can't feasibly use another editor to perform the 'Find in Open Files...' search!

Not having the 'Find in Open Files...' option is almost CRIMINAL!

Keep up the good work and good luck with the new feature.
KISS.

[yuval-gilboa]

@JacksonKearl is right on. This is a long-standing request coming from many users.

4 years passed since we first asked for this feature in #20530. Glad to see someone is finally picking up this very basic request.

We need what you call the search "Universe" selector. But we need additional "universes". Even if you start with just the first one, leave the door open for adding the other options later:

• open files
• modified files
• current file
• current folder
• current project
• workspace (only option today)
• etc

For example, the "current file" option will enable using the search panel also for single files instead of using the inline search, and avoid the confusing and frustating experience of having two different ways for doing search, each with separate sets of commands and keyboard shortcuts.

All this can be done simply by adding one dropdown to the search panel - see mockups below. Very similar to how it's done in Visual Studio and most other code editors.

For more advanced users, the search glob patterns suggested by other users can be added to the include/exclude boxes that also already exists, in this PR or an in separate PR.

[JacksonKearl]

The next insiders introduces a new config, search.experimental.searchInOpenEditors, which controls the presence of a "Search only in Open Editors" checkbox in the workspace search includes entry. (Yes, a checkbox! 😱)

Also, added a "Git: Open All Changes" command to open all changes, together these approximate the secondary ask for a "Search only in Changed Files" mode.

As part of this came general improvements to our internal search infrastructure to support searching in specific file sets. Currently this is only surfaced via the "Open Editors" checkbox, in the future we may open up extensions to contribute custom globs.

[Louis7777]

In #20530 we've discussed custom file sets for search, and in the process the originally simple ask for a way to search in opened editors evolved into a large scale feature request involving extension contribution APIs, new UX, and updates to the search UI.

This issue tracks scaling that back to just searching in opened editors in order to more quickly experiment with various ways of implementing the general feature.

There are two primary proposals for how this might look:

1. "Universe" Dropdown. This is what products like Dreamweaver use, where a dropdown contains a collection of "universes" of files to search:
   ![XyjNz](https://user-images.githubusercontent.com/507708/91241794-68cdbb00-e74e-11ea-97b2-776ae3f5526a.png)

I'll just add my own two cents @JacksonKearl ... see the options in the Dreamweaver image that you posted?

Match case, match whole word, use regular expression; VSCode has all these options.

But it doesn't have "Ignore whitespace". And I don't understand why. And it is frustrating, in my own opinion.
I mean, what if I want to search for a block of code? What if that block of code is there, but the spacing and formatting is different?

The way VSCode's search is currently implemented, for me it is only useful for searching with keywords, not blocks of code. For that, I'll have to keep Dreamweaver around, although I don't use it for anything other than that. Its "Find and Replace" dialog has all that I may need. And yes, being able to search in all open documents is really important as well.

VSCode devs should take notes. It's a shame that such features are missing from an otherwise perfect open source editor. Just my opinion, of course.

[JacksonKearl]

Why not use regular expressions to ignore whitespace? So use \s instead of space.

[IvanPizhenko]

Why not use regular expressions to ignore whitespace? So use \s instead of space.

That's likely possible, but absolutely not convenient

[Louis7777]

Why not use regular expressions to ignore whitespace? So use \s instead of space.

I'll ask you the same. Why not add a fourth toggle (next to "Match Case") that does exactly that for the user - use that specific regular expression internally? Without the user having to do such thing manually.

Also, how would you go about searching using \s, even for a simple small block of code? For example:

function whatever( argument ) {

$myvar='hey, this line has no spaces...';

  if ( something ) {
    // etc.
  } 

}

Would you have to add \s before and after everything just to be sure? Before and after function names, arguments, statements, parentheses, variables, strings etc. ? That will take at least a minute for every search instead of a quick copy-paste search as in Dreamweaver. Plus, the search box is short and it is not convenient to modify blocks of code in there.

I'd rather just use another tool for a block search instead of VSCode. It's a very common search (apparently, the folks at Adobe agree since they offer that option), so I don't think I should be messing with regular expressions for such a usual type of search.

Again, just my personal opinion. VSCode has everything for me, except for the search. I would really like to be able to search in all open editors and to ignore whitespace (by default). I wouldn't even complain if there were any extensions that augmented the search with such features, but there aren't any!

[JacksonKearl]

You can create an extension to perform that transformation if you want. It'd be a matter of acquiring the selection from the active editor (or a quickpick, or the clipboard, etc.), applying a /\s*/\\s/g, and executing the workbench.action.findInFiles command with it as the query argument.

I created the search in open editors feature in core because it was a highly desired feature with no good way for an extension to provide a similar experience, but we can't go adding new checkboxes to the UI for every new variation of a search, especially when extensions can provide the feature already.

[Louis7777]

You can create an extension to perform that transformation if you want. It'd be a matter of acquiring the selection from the active editor (or a quickpick, or the clipboard, etc.), applying a /\s*/\\s/g, and executing the workbench.action.findInFiles command with it as the query argument.

Cool, all that remains now is that I learn how to create VSCode extensions :P

I created the search in open editors feature in core because it was a highly desired feature with no good way for an extension to provide a similar experience, but we can't go adding new checkboxes to the UI for every new variation of a search, especially when extensions can provide the feature already.

If there weren't many people asking for it (because maybe they just didn't reach out or who knows why), you wouldn't still think that it's an important feature to have?

And as for being able to search for blocks of code, don't you think it's a common search? If it is, one needs to be able to ignore the whitespace. Of course, there shouldn't be new checkboxes/toggles for whatever variation of search, but I think that the common ways of searching should have been covered.

In any case, thanks for at least considering it.