Stabilize TextSearchProvider API

[roblourens]

Master issue to track stabilizing the TextSearchProvider extension API...

Forked from #47058

Depends on

• Text search results in API should return all matches on one line in a single result object #59919
• Text search should support context #59458

[suntobright]

looking forward to progress

[mostafaeweda]

Any progress on moving this to the stable API?

[gjsjohnmurray]

Is there anything preventing this from happening? Both of the issues it's shown as depending on are already closed.

[roblourens]

This still isn't ready to be stabilized, I don't have any ETA, sorry.

[eamodio]

There needs to be a 😢 reaction

[gjsjohnmurray]

Any progress to report on getting this finalized?

[gjsjohnmurray]

Please put this on the 2020 roadmap, preferably sooner rather than later.

[gjsjohnmurray]

@roblourens 🙏 can this get some love soon? Those of us building extensions that implement FileSystemProvider can only offer search if we get our users to (a) use Insiders, (b) download and install a VSIX, and (c) launch Insiders with the correct --enable-proposed-api argument.

It is a small relief that (c) can now be achieved using argv.json, but what we really need is the API finalized.

[NightRa]

I'm interested in the stabilization of this as well.
What's blocking this, and how can we help?

[roblourens]

Sorry, it still needs a lot of thinking and I won't get to it in the near future

[gjsjohnmurray]

Sorry, it still needs a lot of thinking and I won't get to it in the near future

@roblourens this is disheartening news for me, and likely for others trying to leverage FileSystemProvider and take VSCode into new domains. Is there any way we can help? What do you see as the outstanding problems with the proposed API?

[CompuIves]

Heyo! I've been following this issue for a while, and I was wondering if by now there's a better idea on when this API will be stabilized. Seeing that there are already quite some extensions using it, even including Microsoft extensions in the marketplace.

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

[roblourens]

This will be one for @andreamah to look at some day

[pattazl]

waiting for TextSearchProvider to the release , not insider. I want to get the matched words by TextSearchResult, not only the whole text by TextDocument.getText()

[isc-bsaviano]

Hi @andreamah, now that 1.74.0 is out and you're in the yearly housekeeping iteration do you have an updates on when this issue and #73524 (FileSearchProvider finalization) may be addressed? They have been stagnant for years and we haven't gotten any feedback on why finalization hasn't happened. For my team in particular, finalizing these two APIs would make a huge difference for our end users. If there's anything I can do to help get these two issues finalized please let me know.

[cfmaer]

I can only agree with @isc-bsaviano. This feature would be very very helpful for us as well.

[roblourens]

Sorry, we're aware that this is an important API for a lot of scenarios. We don't have a specific plan for it at the moment but it is still on our radar. The only reason it didn't happen originally, and hasn't since then, is that it turned out to be a complex API that was hard to design in a way that would be performant and also consistent with the rest of our extension API, and other feature areas have taken priority since then.

[isc-bsaviano]

@roblourens Thanks for the update. Does that comment apply to FileSearchProvider as well? While this is much more important for us, we consume that one as well and therefore have a desire to see it finalized.

[roblourens]

Yes, same status

[JasonHassold]

@roblourens @andreamah Hi, I am currently working on an extension using this proposed API and am a bit concerned that it will not be finalized in the near future. It seems fully functional for my use case in its current state, and I really don't want to have to go the route of implementing a secondary search system outside of VSCode to accomplish the goal of my extension. I think some of the confusion myself and others have around this is that it seems to work fine, and we are missing out on the opportunity to utilize this feature in a meaningful way at the moment.

I think this is a really cool API, and a bunch of useful extensions could be built on top of it. Is there any way to get the priority of this moved up? Or to at least get it semi-released with some sort of performance warning if that is the primary concern?

[kowd]

@roblourens - any chance to revisit this in the future? It will also be very useful for the FS provider I'm building.

[JasonHassold]

@roblourens @andreamah following up on my previous comment, I wanted to share a demo of the extension I'm building to help convey the utility of the proposed API. Here is a Loom video showing what I've built https://www.loom.com/share/5165d909e7184601b09136cd4787198a

It's really a bummer that I have something useful that works, and I can't release it on the extensions marketplace.

[andreamah]

We'll try to get to this in the future! This is definitely on my radar already.

[gjsjohnmurray]

@andreamah please give this the attention it has long deserved. Is it unrealistic to hope this API will get finalized before the fifth anniversary of this issue?

[gbrueckl]

not sure if this fits here but would the proposed TextSearchProvider also allow us to search files from a Custom File System Provider which are not opened in the editor?

[gjsjohnmurray]

@gbrueckl yes it does.

[isc-bsaviano]

Hi @andreamah, just wanted to bump this again now that its the new year. I'm hoping this will finally make it on an iteration plan!