-
Notifications
You must be signed in to change notification settings - Fork 28.9k
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. |
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! |
Update on the progress of this: the internal implementation has been changed to support everything in the last update, minus the type TextSearchResult = TextSearchContext | TextSearchMatch or whether it should more like what is it above with interface TextSearchResult {
uri: Uri,
match: TextSearchMatch,
surroundingContext: {
text: string;
lineNumber: number;
}[]
} We ultimately concluded back on something similar to the latter approach, as it was more friendly to receive when using the After a bit more iterating on the design of the latter, we fell upon something like interface TextSearchResult {
uri: Uri;
range: Range; // target range
preview: {text: string; location: {start: number, end: number}};
contextLines: {text: string; lineNumber: number}[];
} Which seemed clearer to the consumers. Right now, there's some discussion on whether we should have something like interface TextSearchResult {
uri: Uri;
range: Range; // target range
preview: {text: string; location: {start: number, end: number}};
} Where the context lines are included in the preview. Then, context lines could be separated from the preview text by shaving off However, the next steps involve the plumbing to support associating matches with context sooner in the implementation. Since our ripgrep text search has its own provider, we will also need to change how to serves context and matches to the main thread via the API. Full transparency- my time has been a bit split between this and other things, as there are some team priorities that are more urgent. This being said, the timeline is slower than initially anticipated. I've tried to get some of the team testing these APIs (with a version that still splits |
Thanks for the update @andreamah! I assume we should hold off on updating our extensions until you and team have decided on the new shape? |
Yes, that would be great! Thank you @isc-bsaviano :) |
Master issue to track stabilizing the TextSearchProvider extension API...
Forked from #47058
Depends on
The text was updated successfully, but these errors were encountered: