Stabilize FileSearchProvider API

[gjsjohnmurray]

@roblourens I created this issue in the hope FileSearchProvider is going to get finalized at some point. If yes, maybe add the api-finalization label here.

If I'm out of order creating this, or if I've overlooked another issue dealing with its finalization, please close.

[jrieken]

Yeah, it's about time...

[eamodio]

@jrieken @roblourens Can we revisit this -- so we can move forward with some kind of search provider functionality. I've been dying for this for a LONG time now and its blocking really cool use-cases in both GitLens and RemoteHub.

[gjsjohnmurray]

@jrieken @roblourens Can we revisit this -- so we can move forward with some kind of search provider functionality. I've been dying for this for a LONG time now and its blocking really cool use-cases in both GitLens and RemoteHub.

And the TextSearchProvider API too please (#59921) 🙏

[gjsjohnmurray]

@jrieken eleven months ago you wrote:

Yeah, it's about time...

Please can this get onto the April 2020 milestone? 🙏 📿

[jrieken]

This is not my decision, search is owned by @roblourens, I own the API-process which ensures all API look and feels alike

[cfmaer]

Please finalize this, this is really needed to fully implement extensions that use the FileSystemProvider, thanks! Do you need input?

[klaasgeldof]

Any news about this? I'm creating an extension which isn't much worth without this functionality. I tested it and it works perfectly, but unfortunately I can't submit it to the marketplace... @roblourens

[gjsjohnmurray]

@roblourens please can we blow the dust off this and get it into Stable? Or else get an understanding of what's holding it up? IMO as more and more FileSystemProvider implementations show up (aka virtual filesystems) the more important it becomes to resolve this.

[a-boertien]

To echo @gjsjohnmurray, can this please be addressed?
This is blocking adoption of an extension (as we need to rely on a beta version for 'Find Files' functionality), and by extension, blocking adoption of VSCode as the IDE of choice for our application platform.

[gjsjohnmurray]

@roblourens does this also need to be reassigned to @andreamah in order to stand a chance of being finalized?

[andreamah]

I cleaned up the search APIs a little bit. There should no longer be any mentions to New. Rather, "new" versions of the APIs should be suffixed by "2".

This also affects:
#48674
#59924
#59921

[andreamah]

As for API status, our current state can be illustrated as so:

And we are trying to aim for a shape that looks more like:

Unfortunately, I'll be stepping away from VS Code-related work, so I really hope this can get picked up by someone else soon.

[isc-bsaviano]

Thanks for the update and all of your work in this area recently @andreamah! Hopefully this can brought over the finish line soon.

[nsxdavid]

You are stepping away @andreamah ? Oh no... you were our only hope!

[pwang347]

Question for anyone picking this up - will this also be supported for Custom Editors?

I noticed that there are concepts of text/line numbers in the diagrams, but it would be amazing if extensions could have custom handling for focus/highlight behaviour in a custom editor.

[nsxdavid]

Welcome @osortega. We are excited to have you in charge of this!

[naman108]

Just commenting for visibility but this would be a really high helpful addition to the vscode ecosystem unlocking some really high leverage use cases within the community, especially in the domain of NLP.

[isumygin-sc]

I am waiting for it for more than a year - I build a VS Code extension for our cloud platform, but can't leverage VS Code file search and other features, it would be really helpful to have this completed!