build 1573 - lightweight Spotlight integration

Alpha/Beta versions for early access to new half-cooked features
sasha
Posts: 168
Joined: Wed Feb 17, 2016 4:59 pm

Re: build 1573 - lightweight Spotlight integration

Post by sasha » Mon Apr 25, 2016 9:23 am

I often need to navigate to a file or folder anywhere on the disk where I know a part of the name. Without NC, I either use "CMD+Space" in Spotlight GUI, or "mdfind -name ..." when in Terminal. Both allow for quick fuzzy searches without need for wildcards or item order. The latter is especially important, e.g. "mdfind -name author1 author2 pdf" will also find documents where author2 comes before author1 in the file name.

In NC (before build 1573), this workflow is cumbersome. First, one has to go up a few folders ("CMD+Up") since the target file/folder is usually not in the current working directory. Then, in "File->Find" ("CMD+F") one has to use wildcards (*) in the search string because one searches for parts of the file name. The worse problem here is that order matters: "*author1*author2*pdf*" won't find items where author2 comes before author 1. Furthermore, NC's search (in this particular workflow) is significantly slower than invoking Spotlight.

Using NC's new spotlight search ("CMD+ALT+F") can potentially improve the workflow a lot. If one could access substrings of the query like #{query2}..., these could be "&&"-concatenated in the JSON file and one could perform the workflow (exactly like in Spotlight) from NC. Maybe this is not for everyone, but for me this would be a powerful feature and if one wants to do these kind of searches in NC, it's now easy to set up. And it's easy to extend, e.g. "kMDItemTextContent" for content search.

Bottom line for me: fuzzy, order-irrelevant search, less keystrokes for the user, much faster than built-in search.

Thanks,
Sasha

sasha
Posts: 168
Joined: Wed Feb 17, 2016 4:59 pm

Re: build 1573 - lightweight Spotlight integration

Post by sasha » Mon Apr 25, 2016 9:34 am

migun wrote: If one wants to filter filenames by, say, 5 parts - then go ahead and change the format string!
That's quite ridiculous, but any dumb scaling, like multiplying strings and concatenate them with fixed logical AND (&&), is ridiculous too - what if someone needs something different?
Sure, something RegEx-based would be more flexible. IMHO, your simple approach is not too bad. Let's say I concat "kMDItemFSName == '*#{query1}*'cd" && ... && "kMDItemFSName == '*#{query9}*'cd" in the JSON prefs file. That would work fine in my case for up to 9 file name parts. The remaining parts would be && "" && "" ... and wouldn't alter the query.

Again, this would a great tool to have in NC and up to the user to customize.

User avatar
mike
Posts: 1060
Joined: Thu Jul 16, 2015 5:35 am
Location: Exeter, UK

Re: build 1573 - lightweight Spotlight integration

Post by mike » Tue Apr 26, 2016 2:34 am

Aha!
I didn't actually realize that part like "kMDItemFSName == '*#{query9}*'cd" with an empty substring will produce "kMDItemFSName == '**'cd", which in case does no filtering, so it's absolutely ok to have more "parts" in that format than input query string has in fact!
That was the missing puzzle piece, now I've got it.
Indeed, that usage pattern makes sense.

I just have tried the following format string:

Code: Select all

kMDItemFSName == '*#{query1}*'cd && kMDItemFSName == '*#{query2}*'cd && kMDItemFSName == '*#{query3}*'cd && kMDItemFSName == '*#{query4}*'cd && kMDItemFSName == '*#{query5}*'cd && kMDItemFSName == '*#{query6}*'cd && kMDItemFSName == '*#{query7}*'cd && kMDItemFSName == '*#{query8}*'cd && kMDItemFSName == '*#{query9}*'cd
and it works fine for different substrings amount.

sasha
Posts: 168
Joined: Wed Feb 17, 2016 4:59 pm

Re: build 1573 - lightweight Spotlight integration

Post by sasha » Tue Apr 26, 2016 1:37 pm

Great! I'm looking forward to trying it in the next build.

Post Reply