Does search / fuzzy search work?

jack-guy commented 6 years ago

Thanks for fixing #1 so quickly! I'm off and running with the extension, and in terms of speed the experience is already miles ahead of the SSHFS / Fuse solution I've been using.

Search / fuzzy search isn't working for me, however. I noticed there's a separate extension API for that in the FileSystemProvider - provideTextSearchResults. Has that been implemented yet? Would you need any help in doing so? https://github.com/Microsoft/vscode/issues/45000 seems to have some good information.

SchoofsKelvin commented 6 years ago

The provideTextSearchResults seems to be part of the proposed API. It's already available to VSCode Insiders, and might be in 1.24.0, based off that issue and the May 2018 iteration plan.

I might actually start an insider branch and add this feature, for when they actually release it.

jneuhaus20 commented 6 years ago

Looks like it did make it into 1.24. And excited to try this extension out this weekend!

SchoofsKelvin commented 6 years ago

It's still a proposed API, which means it won't be actually released until (hopefully) 1.25

jack-guy commented 6 years ago

Are you looking for help with implementation @SchoofsKelvin? I might be able to chip in.

SchoofsKelvin commented 6 years ago

I've just copied the example from the Release Notes and am rewriting it now to work properly.

I regularly commit and push to the insider branch. Feel free to make any comments (or even commits) on it.

lopugit commented 6 years ago

I would love to help with this too!!! :D can we implement this? does anyone know how? I get the error message "No search provider registered for scheme: ssh" from vscode

SchoofsKelvin commented 6 years ago

I've got a very simple working demo on the insiders branch, but it doesn't seem very efficient.

I'm thinking about using FileIndexProvider.provideFileIndex combined with the find command over SSH. This would force me to use an actual SSH connection, not just a (wrapped) SFTP connection. Currently it doesn't matter, but for later features, it could

Feel free to check out (and improve) the current implementation, or create your own. I won't be publishing it anyway until it moves from the proposed API into the actual API.

lopugit commented 6 years ago

@SchoofsKelvin what do you mean by demo?

I'll sideload the insider build and try it out

lopugit commented 6 years ago

you don't happen to develop on windows 10 do you? I'm actually resorting to running a windows 7 vm to connect to my osx smb share via vscode.... cause WinSshFs works to mount the filesystem but vscode crashes and causes windows explorer to crash too....... and vscode-sshfs, your beautiful program, doesn't have search, yet, maybe we can change that. But mainly windows 10 broke smb to osx so.... fml

SchoofsKelvin commented 6 years ago

I do use windows 10, but I never mount like that. I usually use the terminal, WinSCP and now my extension (although often I just use a git repository)

j-oshb commented 5 years ago

It would be great to see this implemented. Any updates?

benesch commented 5 years ago

I took a stab at the more efficient implementation: #98

Unfortunately the APIs are still experimental and forbidden for use unless you download the insiders build of VSCode.

kaanyurukcu commented 5 years ago

Sad to say but vscode team is planning to nuke FileIndexProvider api 😢 and I guess we need to use FileSearchProvider...

https://github.com/Microsoft/vscode/issues/59922#issuecomment-439323504

sflc6 commented 5 years ago

Hi - wanted to follow up on the status of this.

Thanks!

SchoofsKelvin commented 5 years ago

The extension API for searching is still in development, and constantly changes. Until it's stable and (close to being) released, I won't be working much on this. Without a proper release, only insiders would be able to use this anyway.

I might create an insider branch once I have more time. It seems like I'll have to actually search files on the remote host using ripgrep or something similar, which would have to be cross-platform, efficient, and (more or less) support what the extension API requests. Still, not too keen on starting this without being sure about what API we'll eventually end up with.

Keeping track of Microsoft/vscode#59921, Microsoft/vscode#59924 and related issues.

SchoofsKelvin commented 5 years ago

Writing some initial code on the feature/search branch. I just pushed a commit (119f2bdc) that adds a very basic FileSearchProvider with session caching, adding support for ctrl+P. It runs the ls -AQ1R <path> command on the remote system, which is far from ideal, but currently kind of works.

I'll probably just have to "manually" go through subdirectory by subdirectory and check against e.g. the includes/excludes/useIgnoreFiles/..., to increase efficiency and accuracy. The basic implementation just lists every file (indirectly) under the target folder and then checks the search query against it, which is inefficient and also wrong.

Once that's properly working, implementing TextSearchProvider (for ctrl+shift+F) should be relatively easy to implement.

SchoofsKelvin commented 5 years ago

The FileSearchProvider now doesn't run a command anymore and supports the exclude glob patterns (543c95c)

Also implemented the TextSearchProvider (736e415) which is decently fast. It basically uses FileSearchProvider to list all files to be searched, then looks for RegExp matches in them, based on the search query and options (e.g. case sensitivity) and reports them. The extension currently can search 20 files at a time, which I think is a nice balance between speed and not overloading the network.

Tips for searching efficiently and especially fast:

Make sure to enable Use Exclude Settings and Ignore Files
If possible, add some (top-level) folders to files to exclude, e.g. node_modules Both of the above methods will limit the amount of folders to traverse. If the extension hits a folder that's excluded, it won't waste time scanning it. Otherwise, it'll scan everything in it recursively (unless excluded lower down).
Make use of files to include to limit which files to read, e.g. *.js The extension will traverse every directory that isn't excluded, even if it is not "included". That's because if you include sub/folder, I can't skip test because test/.../sub/folder can exist. The include filter will, after all folders are traversed, only keep the paths that are included. If you don't include anything (thus everything), the extension will also scan e.g. .png files

So basically, the search progress goes like this:

Traverse everything recursively (unless a folder is flagged as excluded, then that folder will be ignored)
From all the results, only keep the ones matching the include patterns
For every resulting path, scan for the text inside

This code is currently only pushed to the feature/search, open for improvement and feedback. It's marked as insider, but currently it is not published. I might publish it for insiders the following days, after testing a bit more. It won't be publicly released until some of the search API moves out from the proposed stage into the officially released stage. (keep track of Microsoft/vscode#59921 and Microsoft/vscode#59924)

SchoofsKelvin commented 3 years ago

Small update: Still waiting for the API to be officially released, see microsoft/vscode#73524.

progettoautomazione commented 11 months ago

Hello, I've just installed it on VS Code for Browser and despite any possible setting-changes attempt, it keeps findign items only in my open editor files. Anyone having the same issue?

Esther-Goldberg commented 7 months ago

@progettoautomazione I'm seeing the same, it loads for a long time but only finds things in my open files.

ammannbe commented 5 months ago

+1

Also interested in a working search, since VSCode Remote SSH don't work on our systems and this extension would be a great alternative.

SchoofsKelvin / vscode-sshfs

Does search / fuzzy search work? #2