-
Notifications
You must be signed in to change notification settings - Fork 28.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize TextSearchProvider API #59921
Comments
looking forward to progress |
Any progress on moving this to the stable API? |
Is there anything preventing this from happening? Both of the issues it's shown as depending on are already closed. |
This still isn't ready to be stabilized, I don't have any ETA, sorry. |
There needs to be a 😢 reaction |
Any progress to report on getting this finalized? |
Please put this on the 2020 roadmap, preferably sooner rather than later. |
@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. |
I'm interested in the stabilization of this as well. |
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? |
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. |
@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. |
Hmm, that's a good argument to keep some type of base |
@andreamah I've never tried that API but I can confirm that when using the Search view in a multi-root workspace folder and adding a "files to include" glob that only matches a single folder, the |
I'm not too sure what you mean by this statement? |
After a bit more of API review, a question came up: how important is @ the people who are using this API, do you use the If not many people are using it, we might consider keeping this part in particular as proposed to simplify the overall finalization process. |
@andreamah I use it to notify the user that there were errors for a certain number of documents and to check our Output channel for more info. I could easily replace this with a call to |
An update. These are the latest changes to the API via diagram: Some major-ish changes compared to the last time i shared:
As usual, the changes are here. I'm making all the changes at once due to the intertwined nature of the changes between the search APIs. Also, please note that these changes might take some time to clean up. I am finalizing the shape of the API, but I also need to make appropriate internal changes and do testing. So this might take a while to actually finalize. |
Thanks for the update @andreamah! I have a few questions:
|
@isc-bsaviano thanks for reviewing my blurb!
Yup!
No, this is not guaranteed. You will need to see whether, if the exclude has a |
Thanks @andreamah, that's all good to know! Is there a reason why VS Code will no longer be "pre-processing" the exclude globs (filtering out ones that don't apply and turning the rest into strings relative to the workspace folder root)? It's still being done for includes. I will keep my eye out for when this is available so I can update my implementations. |
@isc-bsaviano do you mean having all of the strings relative to one workspace root? The reason was because In the case of doing a search from the UI, we will try to keep the options as clean as possible, which likely will involve filtering out and modifying exclude patterns to be friendly with the current With |
Thanks @andreamah, that makes sense |
Hi @andreamah, one more quick question about the new APIs. Does |
Good question! |
@andreamah In version 1.92 I see new proposed APIs |
Hey @andreamah, thanks for your great work on this. I've been developing a "semantics" search system called TSearch, and I'm curious if it would qualify as a TextSearchProvider, or if it perhaps falls outside the scope of this API. Would love to hear your thoughts. Rather than taking the "code words" and generating an index of text, it constructs an index where each code word is encoded with its semantic "context". Take, for example, this javascript snippet: function hello(name) {
console.log("Hello", name);
} In addition to including the word Anyways, the reason I'm describing all this is because the "query language" used to search this index isn't exactly text, it's got a few simple rules and operators in order to distinguish which parts of a query are for context ("function") and which are for content ("hello"). It's not as gnarly as regex, not even close, but it's definitely not "just" text. I see that Regardless, I don't think my question needs an answer before the Let me know if any of this needs clarification. Thanks! |
This isn't ready to be consumed- I'm just creating these so that I can start changing the internal implementation without affecting the existing proposed APIs (since some internal extensions currently use it). |
Thanks for the clarification and for all of your hard work to help make this a reality! |
@caleb-allen Great question! For the most part, this API is meant to be consumed to simply search for 'text' as-is. For example, if you create a custom filesystem, this API helps with actually understanding what it takes to get search results from your project. This being said, it was not necessarily created to facilitate a special or 'intelligent' search that requires custom options. The reason why the options have things like |
I see, this clarifies things a lot, thank you! It seems that the behavior I'm trying to construct may be better achieved with other APIs, an "enhancement" on search, rather than modifying the deeper plumbing of all search. Thanks for your answer! |
Master issue to track stabilizing the TextSearchProvider extension API...
Forked from #47058
Depends on
The text was updated successfully, but these errors were encountered: