Suggestions • Re: DIY Debugging of Search Strings

It might be easier to view the search tree in the log:

And here I am on the Acer Aspire, Win11 latop.
I think I must be suffering from Refrigerator Blindness
Attached is the log file from a few minutes ago.
I can locate lines that contain "File Ops", but in no way do I see any sort of tree structure.
I understand OpCodes and tokenizing, but " 5 is a normal search, 232 is a size search and 234 is a dm search." leaves me stranded.
How is a novice user supposed to understand this tree structure, once it is located?

When I think of debugging a search string by the end-user (as distinct from The Developer) I think of the original search string provided by the user - or possibly re-arranged in optimal order by a per-processor, looking something like this:-with a caret indicating where the results List dropped to zero items.

Better yet would be a numeric indicator:-with the Result List population at each successive step.
In the example above I might ask myself "Why is there such a huge drop when I isolate results to Z:, my mammoth global all-time backup drive?"

Perhaps with the right knowledge of Op Codes and other tags one could write a "debugging file translator" that could construct, from the verbose data, the data that the user needs in order to identify weak points in their constructed search string, but that sounds like a lot of work to document what must, surely, be available as Everything works its way through a search string?
Cheers, Chris

Everything Debug Log-1.5a.txt

Statistics: Posted by ChrisGreaves — Tue Sep 03, 2024 9:43 am

---