Major File Search Window Update - 6.3.0.55 beta 🌟

since I update to version 6.3.0.59 it is not working well.
For example I used it to start MSTSC and it always find it as firts entry (as I use it a lot)
But now I don’t find it at all.

I haven’t touch any settings after the update.
Thanks for any sugestion

I downgrade to listary 6_3_0_51 and I get back the good behaviour.
If I search MSTSC the first time I get

And the next time I search the term it is listed in first place.

This doesn’t appears with .59 update.
I think it was ok with .57 update but I haven’t been able to check it back because I havent’ been able to recover my previous installation with .57.

Hope this help . Thanks

v6.3.0.57 has changed some built-in priority rules:

Improved:Refined index priority handling for better result ranking and reduced memory usage.

And this change makes programs under C:\Windows\ ignored by default. You can search for “Remote Desktop Connection” instead, for example:

Thank you for the explanation
I can understand this option improve.
But I can not understand is mstsc.exe doesn’t appear even when I type the full name.
Why ignore c:\windows files? This is where majority executables files are…
There must be some reason. Thanks

I’m not the product manager. However, if you want you can remove this rule:

Remove %SystemRoot% from the Low Priority
and add it to the Normal Priority.
Works fine then.


Windows 11 Home x64 Version 23H2 (OS Build 22631.2715)
Listary Pro 6.3.0.59

@Channing can you bring back support for ListView windows class in Listary 6 ?
my issue: qttabbar’s ‘compatible list view style’ toggle (that enabled the old ListView window class for file explorer) used to work fine with listary 5, but with listary 6, type directly to search doesn’t work at all in explorer when qttabbar is installed with this toggle activated.
related posts:

I’m not the product manager

So, you are part of the development team?

Yeah, I joined since v6.0.11.34, though not full time.

1 Like

Ok. I have another question, I was looking at your account on GitHub and one of your repositories is lbEverythingExt, so I was wondering if you are part of the development team, can you tell me if Listary has the Everything library integrated? Several launchers such as Wox use this library, and since Listary finds results quickly, I don’t know if Listary is using your project or something similar.

No, Listary now uses a Rust engine we developed (previously it was written in C# / C++). The only thing of lbEverythingExt that is used in Listary is its pinyin match algorithm.

Using Everything as the search engine has many limitations, such as the API doesn’t support incremental search and getting massive results can be slow (I’ve developed an optimized C++ implementation for Everything’s IPC API: IbEverythingLib: A C++17 library for voidtool’s Everything).

Okay, thanks for the clarification. Since version 5 I was always wondering how Listary could find results quickly without using the Everything library, it’s magical.

I am happy with how Listary has been developing, since Channing disappeared for a while I thought that Listary would never be supported again, but now that he is back in charge it is a good reason to continue supporting Listary.

You have a long way to reach the functionality of Everything 1.5 in Listary.
I use both tools, but currently Listary can’t beat Everything in any aspect.

I agree that Everything is robust and powerful in terms of file searching. If I’m going to develop a file search app from scratch, I would choose to integrate Everything. But that’s not the case for Listary. Listary can do fuzzy search and pinyin search with priority rules applied, while Everything can do neither of them (without some nasty reverse engineering like I did in lbEverythingExt). In the future, there may be more features that only Listary has. Though I can’t say whether Listary will eventually be as powerful as Everything, as making another Everything doesn’t make much sense and users can just use both.

1 Like

I am sure this is planned - but for now there is no multiselect in the large Listary Window possibly. Hence, one cannot select a bunch of files an move them somewhere else.

Any chance of adding an “exact match” option? That would be super helpful. We are using scannable barcodes on in house travelers to help our employees find files, but sometimes they will manually type a search in and could enter incorrect file info . Example: part# 0410211 vs part# 041021. If they manual search it currently will display both numbers and can create confusion for some.

Sure! This is planned.

NICE! Looking forward to it, thanks!

Is “Open File’s Folder” planned?

You can use “Ctrl +Enter” to open file’s folder.