Thanks for the information. I’m still optimizing the sorting algorithm, and the following changes would help: favoring exact matches (vscode), showing exact pathes first (d:\apps\vscode).
This is indeed a problem of result priority because Listary only shows the top 30 results. Some possible reasons for this case:
vscode folder is marked hidden or system.vscode's modified date is too old.Simply press Ctrl + Enter.
OpenUrl is the only supported one at the moment for demo purposes. There will be many more in the stable release.
P.S. I’m also a big fan of TypeScript, and you’re likely to see some official TS support in the future.
Hey Channing, I’m currently establishing a paperless office at home and gonna have OCR recognized PDF files for that purpose. Could you please consider extending your file indexing engine with PDF text search? That would be the absolute killer feature 
Blockquote
vscode folder is marked hidden or system.vscode 's modified date is too old.1.folder is not hidden
2.folder’s modified date is 12-Feb-2019
Blockquote
favoring exact matches (vscode), showing exact pathes first (d:\apps\vscode).
I think it should favore exact matches first, but also shorter paths first, e.g. (d:\ vscode) would match all of the following:
D:\apps\vscode\
D:\apps\vscode\data\tmp\vscode-typescript
D:\apps\vscode\resources\app\extensions\ms-vscode.node-debug2\node_modules\vscode-nls
I think it should show them in this order, the shorter path is usually the more likely one. Currently Listary shows long/short paths based on other criteria.
I’m not saying it should always sort by path length, but could also take filename length and path length that into the consideration criteria.
Hi, Channing.
Can you please make sure to add notes to the Change log after your next release? You didn’t for 6.0.2.12. Thanks in advance.
Such info is already available using the Windows index with PDF IFilter.
Why should this be duplicated in Listary ?
Others want to search for DOC or DOCx content and so on…
All of this is available with the Windows index.
The only useful implementation of such searches in Listary
would be to using the installed iFilters.
Sounds like a plan, I believe Listary currently does not support Windows Search as source. I don’t use Windows search, I just use Listary for locating files / folders.
Awesome! Will Listary extensions be published and installed via npm?
I imagine you can require extensions to be publishes with a keyword “listary-extension”. This will enable listary to search for extensions, show a list, and install them. This extension-management behavior can even be implemented as an extension.
That will be like Sublime Text package control.
@Channing I expect that we can directory manage plugins in the Listary search bar with command such as plugin install, plugin list, plugin update, plugin uninstall etc…
You should add more metadata (like file size) in the search results. There’s ample room on the right.
There is no plan to add file content search support directly to Listary, but using Windows Search is an option.
I’ll definitely consider that option.
Sure. 6.0.2.12 just fixes some minor issues of 6.0.2.11, so I didn’t add a new changelog entry.
The current plan is to use GitHub repos. You create a repo for an extension, and users can install it by simply pasting the URL.
Search can be supported by using tags/keywords as you described, or by submitting the extension repos to a centralized list (can also be a GitHub repo).
According to my experience with VS Code, it’s not as intuitive as UI.
I do plan to show more information about search results. And of cause, it’ll be optional.
We will see when it comes out.
I like it
I know you have a lot on your plate but when you are able to implement selecting multiple items from the search results, take a look at how it’s done in Alfred (for Mac) in this video (at 8:40’)
