Does search / fuzzy search work?

[jack-guy]

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? microsoft/vscode#45000 seems to have some good information.

[SchoofsKelvin]

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]

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

[SchoofsKelvin]

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

[jack-guy]

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

[SchoofsKelvin]

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]

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]

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]

@SchoofsKelvin what do you mean by demo?

I'll sideload the insider build and try it out

[lopugit]

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]

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]

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

[benesch]

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]

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

microsoft/vscode#59922 (comment)

[sflc6]

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

Thanks!

[SchoofsKelvin]

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]

Writing some initial code on the feature/search branch. I just pushed a commit (119f2bd) 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]

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]

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

[progettoautomazione]

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]

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

[ammannbe]

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