search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.5k stars 28.65k forks source link

Stabilize FileSearchProvider API #73524

Open gjsjohnmurray opened 5 years ago

gjsjohnmurray commented 5 years ago

@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 commented 5 years ago

Yeah, it's about time...

eamodio commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@jrieken eleven months ago you wrote:

Yeah, it's about time...

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

jrieken commented 4 years ago

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

cfmaer commented 3 years ago

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

klaasgeldof commented 3 years ago

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

franka107ic commented 3 years ago

Hi, @roblourens could you tell us how this problem is developing? thanks and regards.

gjsjohnmurray commented 3 years ago

@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 commented 2 years ago

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 commented 1 year ago

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

r3m0t commented 1 year ago

@andreamah should my extension respect FileSearchOptions.maxResults? Or is the correct behaviour to return all results and let VS Code rank them?

From my testing it seems better to return all results (specifically for Ctrl+P behaviour)

gjsjohnmurray commented 1 year ago

@andreamah do you still own this area? Either way please can we get this API finalized?

Pinging @kieferrm for iteration planning.

andreamah commented 1 year ago

Yes, I do own this area. I will try to keep it in mind the next time iteration planning comes up, but it also depends on whether I have the time to take this on (I don't want to promise to tackle it just to put it aside again). Apologies for delaying this further.

isc-bsaviano commented 1 year ago

Thanks @andreamah! Getting this and #59921 finalized would be a huge improvement for our end users.

eamodio commented 1 year ago

@andreamah Do you what still needs to be done here for this to be stabilized? These search APIs have been around for many years and are used by many "1st" party extensions.

andreamah commented 1 year ago

It looks like the API was worked on and put aside quite a while ago, so we just need to look back into it and ensure there weren't any big blockers on it (and polishing it). For example, considering whether we allow extensions to also control how the result sorting and filtering works.

nsxdavid commented 1 year ago

Love to see this move to the stable API. It's used in the internal extensions, and is a really key capability that's otherwise missing.

d12 commented 6 months ago

It's been almost 5 years since this issue was opened, I'm really hoping to get search working in VSCode SSHFS! @andreamah is there any update on this? Or is there someone else we can re-assign to? Thanks

isc-bsaviano commented 3 months ago

@andreamah Now that you're reviewing this API, can you add some clarification for how implementers of this API should interpret query.pattern? For example, here's the very detailed description of WorkspaceSymbolProvider's query argument:

The query-parameter should be interpreted in a relaxed way as the editor will apply its own highlighting and scoring on the results. A good rule of thumb is to match case-insensitive and to simply check that the characters of query appear in their order in a candidate symbol. Don't use prefix, substring, or similar strict matching.

Should this API's query.pattern be interpreted in the same way? If so (or if not) can the API's description say how it should be interpreted?

andreamah commented 3 months ago

Good point. I created https://github.com/microsoft/vscode/issues/214175 to track that. Do you think you'd benefit from an alternative method of fuzzy matching and highlighting that is custom-defined? I would assume that something like what we have for WorkspaceSymbolProvider should be sufficient for this API?

isc-bsaviano commented 3 months ago

Something specific to our file system is that for some folders, the actual name of the document is different than the path.basename of the Uri. For example, we'll have a document in our file system called User.Test.cls, but the Uri in VS Code will be something like isfs://iris:user/User/Test.cls. Even though our provider returns that Uri for a query like User.T, VS Code filters it out. It would be nice if VS Code would "trust" that our provider is returning results that make sense and only rank our results rather than filtering them too. I'm not sure if that's a common problem though so I understand if making an API change to support this isn't reasonable.

andreamah commented 3 months ago

I had a conversation with @TylerLeonhardt, who takes care of the quick picker and more UI-facing part of presenting search results, and it seems a little tricky to add logic for this. For a bit of context, the ranking/filtering/highlighting happens on the side of the picker.

The reasons we'd be hesitant about supporting custom highlight/filtering logic are as follows:

I hope that sheds some clarity on why we'd likely just keep this the way it is.

nsxdavid commented 3 months ago

Profoundly grateful this is getting attention. I've had to create my own "quick pick" up until now, which is just not very user-friendly as it's a separate command (and thus probably key binding) from what they expect.

I would utilize custom fuzzy matching if it was available, but can live without it.

As they say, perfection is the enemy of done.

isc-bsaviano commented 3 months ago

Thanks for the explanation @andreamah, that all makes sense! I can definitely live without any custom fuzzy matching.

isumygin-sc commented 3 months ago

Thanks for starting looking to it @andreamah! It would be great to have a proper cloud search integrated into our extension.

andreamah commented 2 months ago

Some news: in case you missed it, I'm finalizing this API with some other related APIs. You can see the status (plus a diagram) here. Since they're so intertwined, I felt that it made the most sense to me to address all the APIs as a group.