Quick Search Dll - clarification / strange behavior

[Samuel]

Source of the question.

The TC quick search plugin is used to:
- 1. filter the file panels
- 2. filter search results in file panels
- 3. TC11: filter the list of open tabs
- 4. TC11: filter the list of recently visited directories

Dear @Christian, can you please clarify if the current behavior is intended?

a) A folder like "C:\abc" is given to the plugin as "abc" when searching for "a" in the place 3.
b) A folder like "C:\abc" is given to the plugin as "C:\abc" when searching for "a" in the places 1, 2, 4.
c) A folder like "C:\abc" is given to the plugin as "C:\abc" when searching for "*a" in the places 1, 2.
d) A folder like "C:\abc" is given to the plugin as "C:\abc\" when searching for "*a" in the places 3, 4.

(d) sounds like a bug to me. It results into QuickSearch eXtended 2.9.9 thinking there is an empty file name, finding nothing when searching for a string starting with "*".

[ghisler(Author)]

Yes, it's indeed a bug, it should always pass the path without trailing backslash to tcmatch.dll. I will change it. Please test with the next beta.

[Samuel]

If it is a bug, then you should consider to change the TC quick search plugin, because if you remove the "\" in the end of the foldername, then the plugin can't determine if it filters a normal folder with a filter of "*..." where there is no special meaning of the "*" or if it filters the plugin from the places 3 and 4 (and it is intended to filter the whole path).

I would propose to change:

Code: Select all

int __stdcall MatchFileW(WCHAR* wcFilter, WCHAR* wcFilename)

to

Code: Select all

int __stdcall MatchFileW(WCHAR* wcFilter, WCHAR* wcFilename, int Source)

[ghisler(Author)]

Does it matter? In both cases, the * at the start means that the found text may start anywhere in the search string.

[Samuel]

That would be a bad idea for filtering in place 1 (file panel):
There is always the same folder for each file. So a search with "*..." for a folder part would result in finding everything or finding nothing.

[ghisler(Author)]

But in the case of file panel, TC only passes the name to quick search extended, not path+name!

[Samuel]

Example:

Code: Select all

C:\abc\def\1.txt
C:\abc\def\2.txt
C:\abc\def\3.txt

Search for "*abc" finds every file.
Search for "*deef" finds no file.

[Samuel]

IMO the whole file is passed (what is good, because some advanced users want to evaluate plugins on that file). Otherwise I wouldn't know, where the file is located.

[Samuel]

Mh. Perhaps it would be consequent to use the "*"-Syntax everywhere.

[ghisler(Author)]

I'm currently adding a new function MatchFileEx with a 3rd parameter "flags" which can tell the DLL various states MatchFileEx will always be called when it's present, otherwise the older MatchFile will be called (for compatibility with older versions). Currently I'm passing 2 groups of flags to the matchfile dll:
1. The location where it was called:
MatchFlags_FileList=1;
MatchFlags_SearchResults=2;
MatchFlags_Synchronize=3;
MatchFlags_History=4;
MatchFlags_TabTitles=5;
MatchFlags_TabPaths=6;
2. Special flags which are combined with the above:
MatchFlags_LeftSide=0x100; //search occurs on the left side
MatchFlags_QuickFilter=0x200; // quick search filter enabled (will be called with all files in the list for filtering)
MatchFlags_WatchDirs=0x400; // watch directory changes added another file while a quick filter was active

Is there any other information you would find useful here?

[Samuel]

When implementing the plugin I found it strange that there is no "folder changed"- or "search started"-/"search ended"-indicator.

Currently there are calls like this:

Code: Select all

MatchFile("C:\a\file 1.txt")
MatchFile("C:\a\file 2.txt")
MatchFile("C:\b\file 3.txt")

Perhaps it would be good to indicate the search start/end like this:

Code: Select all

StartMatch()
MatchFile("C:\a\file 1.txt")
MatchFile("C:\a\file 2.txt")
EndMatch()
StartMatch()
MatchFile("C:\b\file 3.txt")
EndMatch()

Perhaps "StartMatch" could pass the flags you mentioned. If I remember correctly that would have made the implementation easier at some point.


Another useful extension would be to add something like more result groups. Currently only "not found" (0) and "found" (1) is a possible result.

It would be nice if there would be something like: "not found" (0) and "found at beginning" (1) and "found anywhere" (2).

Even more result groups are possible: "Levenshtein distance 0" (exact match), "Levenshtein distance 1" (one char differs), "Levenshtein distance 2" (two chars differ), ...

If you don't want to sort the result by the result groups (that would be nice), you could consider to color the different result groups differently.

I think 3, 4 or 5 result groups would be a great improvement. (Also 3 result groups would be nice!) n-result groups would be even better, but you would need to sort the list then.

[ghisler(Author)]

Perhaps "StartMatch" could pass the flags you mentioned. If I remember correctly that would have made the implementation easier at some point.

I will send a parameter MatchFlags_FirstMatch=0x800 for the first call of MatchFileExW in quick search. Notifying the dll when the quick search window is shown/hidden canot be done with MatchFileExW, it would need extra functions. I will consider it, but since you have to support MatchFileW too for older TC versions, there will not be any real benefit.

Another useful extension would be to add something like more result groups.

Unfortunately this doesn't fit at all in the current quick search or quick filter implementation:
1. For quick search, typing another character would jump to the next match without changing any sort order.
2. For quick filters, it would also be strange if the sort order changed. And coloring is currently used for colors by file type
Maybe you have another idea on how to show groups?

[Samuel]

Isn't 400 used here:

Code: Select all

MatchFlags_WatchDirs=0x400

Shouldn't it be 800:

Code: Select all

MatchFlags_FirstMatch=0x800

Its a good idea to remove the need of other function-calls, by adding flags like "FirstEntry" and perhaps also "LastEntry". (I would prefer "FirstEntry" over "FirstMatch" as there is not necessarily a match:

Code: Select all

MatchFileExW("file1.txt", "a", MatchFlags_FileList | MatchFlags_FirstEntry)
MatchFileExW("file2.txt", "a", MatchFlags_FileList)
MatchFileExW("file3.txt", "a", MatchFlags_FileList | MatchFlags_LastEntry)
MatchFileExW("file1.txt", "ab", MatchFlags_FileList | MatchFlags_FirstEntry)
MatchFileExW("file2.txt", "ab", MatchFlags_FileList)
MatchFileExW("file3.txt", "ab", MatchFlags_FileList | MatchFlags_LastEntry)

The main advantage of something like this would be to process the search string only once. (For example if it is a Regex.)


Regarding result groups:

I only think about quick filters here, you are right quick search is hard to improve. However I use quick filter 100% of the time.

I agree, that sorting is a lot of work.

I think that some text highlighting would do great: Bold, background color, foreground color, ...

Colors by file type is a small conflict for some users (I don't use them), you could either disable this "colors by file type" temporarily when quick filtering or you could extend the "colors by file type" with a new "colors by quicksearch result group"-syntax. So every user could choose how to color it.

[ghisler(Author)]

Shouldn't it be 800:

Yes it should, MatchFlags_WatchDirs is already 0x400.

MatchFlags_LastEntry can't be sent, at least when MatchOptions_nointernal isn't set, because then the dll is only called when the internal filter doesn't find anything.

[Samuel]

For Quick Search eXtended that is the case. Sending it only if MatchOptions_nointernal is set is fine.