The Robservatory

Robservations on everything…

 

Spotlight’s odd definition of a match

Tonight, while doing some testing for the ever-growing discussion about my Macworld Spotlight writeup, I stumbled across yet another ‘feature’ of Spotlight that I just don’t get. I’m think I remember reading this somewhere in the hazy past, but it slipped my mind when I wrote the long article for Macworld. But after playing around some more, this new ‘feature’ has jumped well up on my list of Spotlight annoyances.

So just what is this ‘feature’ that bothers me so? It’s this:

Spotlight will, by design, not find exactly what you asked it to find.

At this point, you might be saying ‘huh?,’ but let me explain by way of a simple demo.

Open TextEdit, and in a new blank document, add this one line of text:

the under over be fore ate desktop zoo

Save the document, and then give Spotlight a bit of time (it won’t take very long) to update its index. Now, using either Command-F in the Finder, or Command-Space, run a Spotlight search for those same words:

the under over be fore ate desktop zoo

How many results would you expect to see? In my case, I was certainly expecting to see just one, as I’m positive I don’t have any other documents on my hard drive that have that exact combination of words (in any order, of course, since Spotlight won’t do phrase searching). Note that you might have to change the words slightly; if you find only one match, repeat the experiment, but without desktop zoo at the end, for example.

Update: I have modified the following paragraph to note that Spotlight only matches wildcards at the end, not at the start and at the end. Based on a comment below, I did some more testing, and that certainly seems to be the case. However, I still have a file that showed up in my matched query that doesn’t contain ‘ate’ anywhere at the start of any word, so I’m a bit stumped…

On my machine, that Spotlight search finds not one, but 32 matches! Why so many? Because Spotlight treats every word as if you had added a wildcard at the end of its name—my search was really the* under* over* be* fore* ate* desktop* zoo*. (I believe this behavior is documented somewhere in the Developer docs for Spotlight…but it is not, as far as I can tell, documented anywhere in the user documentation.)

In my example Spotlight search, the Final Cut Express User’s Manual was one of the matches. Why? Because it contained all of these words:

  • The, understand, overview, be, material, desktop, zooming

Now, I realize my example is somewhat contrived, but the question is why does Spotlight show me matches for documents whose words don’t even vaguely resemble my search terms? If I had wanted to do a wildcard search, I would have included them (if they were allowed, sigh). If I had wanted to find the word material, I would have searched on that, not ate. Can someone explain to me how this logic makes any sense at all? I’d also love to know how to find only the words I want to find, and not all words built with those characters. I believe you can do this via the command-line interface, but is it really not possible in the Finder and/or Spotlight search box?

And am I alone in thinking this is a really poor default method for Spotlight to operate in? I certainly wouldn’t expect a Google search, for instance, to return ‘material’ when I typed in ‘ate.’ Why does it make sense that Spotlight does so?

12 Comments

Add a Comment
  1. No, this strikes me as a very Apple way to do it. Basically it can be a little more complex if you know exactly what you’re doing, but if you’re guesstimating you’ll get a good result.

    In your example, spotlight will return items with “material” if you just type “mate”, and that seems a pretty standard and likable real-time search method. The only twist is that they’re making it consistent by doing type-ahead AND type-behind “completion”.

    And of course items with the literal string WILL be the first (most likely) results from Spotlight, it’s not like you have to go digging through dozens of items to find the one that literally matches.

    All that said, you’re right that it would be good to have a straightforward mechanism for searching literally with spotlight, like putting quotations around the string.

  2. It makes sense to me only because I can’t think of a better solution (other than allowing quoted phrases). Here are some examples of searches I use rather often (in this case, I was trying to find a garageband song whose filename was something like day*.band):
    .band
    day .band
    day

    Each of these searches finds the file I’m looking for because of the method you mentioned. This really isn’t a contrived example, it’s the way I search, using beginnings of words and endings of words. Also, the search-as-you-type idea goes down the drain because without it Spotlight won’t find the item you are looking for until you’ve typed the entire word, after which you might as well just hit return. (In some cases I agree this behavior would be preferred.) The problem is, Spotlight doesn’t know whether you’re typing the beginning of a word or end of a word. It can’t read your mind. Wildcards aren’t newbie-friendly enough.

    Strangely enough, Spotlight won’t find Daydream.band if I try these searches:
    dream.band
    dream

    In short, the current implementation makes sense to me and for the most part corresponds with what I search for naturally, though Spotlight is definitely lacking in certain areas and shows unpredictable behavior.

  3. It seems like the logical behavior is to do find-ahead wildcard search, with space and period as escape characters.

    That way, Nethanials “mate” example returns the desired file, as do PCheeses “.band” “day .band” and “day”, as well as the currently non-functional “dream.band”

  4. You don’t have it quite right. Spotlight searches behave like this: the* under* over* be* fore* ate* desktop* zoo*

    For example, if you create a file that contains “beezlele”, searches for “eezlele” will be empty.

    I actually noticed this behavior a few weeks ago when I implemented my own little indexed searching algorithm (I implemented a Spotlight-like search of my Windows start menu)

    Any “find as you type” feature must initially do only partial matching on the current word the user is typing. The question is do you throw out the partial matches after the user hits the space bar to separate the word, or do the leave the partial matches in the list. I had planned on dropping the partial matches but found that the search was more useful when the partial matches were left in. I then checked what Spotlight does and to my complete surprise they do the same thing.

    Google Desktop search, on the other hand, does indeed throw out the partial matches when the user hits the space bar.

    You can take advantage of this behavior if you know it’s there, but I suppose it’s a matter of personal preference. Personally I like that I can launch Remote Desktop Connection by typing “r d c”, however, there doesn’t seem to be a way to force Spotlight to do a whole-word match. Then again, I’ve never actually needed or wanted to do a whole-word match in practice.

    I do know that even though Google Desktop search uses much faster and more sophisticated searching algorithms that Spotlight, I still find Spotlight to be much more useful in everyday use (that is, I haven’t yet found a practical use for Google Desktop, yet I use Spotlight every day)

  5. I’ll agree with some of the other posters that find-ahead wildcard searching is logical, and I’ll tell you why – in fact, it responds to one of your complaints about Spotlight.

    Say I want to find any document on my Mac that has the word “Walden” in it. I start typing Wald… and Spotlight shows results. This provides faster results, but also allows Spotlight to give results without your having to type the entire word. (Since you find that Spotlight’s re-searches each time you type a new letter are too long, you should be happy with this :-)

    However, I will agree that there should be an “advanced” syntax – some way of limiting searches, perhaps with quotes, to precise words or strings. (As we know, quotes limit the search to file names, mail message subjects, bookmarks and contact names.)

  6. Regarding #4 about how it matches … when I searched the FC Express user guide for ‘ate,’ I found 0 words that began with that phrase. I ran a search (in Preview) on ‘ ate,’ and it came up empty. As a test, a search on ‘ the’ found what was expected — all occurences of “the” preceded by a space.

    The only matches I could find for ‘ate,’ though, were either in the middle (material) or at the end (associate). So why was this document considered a match then, if it’s searching on ‘ate*’?

    I guess I’m in the minority; I don’t see any logic in showing matches for words that I didn’t type, unless I explicity request them via a wildcard. But then again, I hate this find-as-you-type feature, too, so I guess it makes sense.

    -rob.

  7. #4: If you want a great (top best ever) application launcher, I would take a look at quicksilver. It kicks spotlights ass on my Mac Mini. spotlight is way to slow to use to quickly finding an application, but Quicksilver is really fast and it gives me the “alt+f2” KDE run application menu feeling.
    I couldn’t live without quicksilver, but I could live without spotlight.

  8. The thing about QS and Spotlight is that they really can’t be compared, since they’re totally different paradigms. I wrote an article enumerating this here

    (does html work? we will find out)

  9. Yeah, there really needs to be some search refinement in Spotlight, preferably something under the user’s control.

    I wanted to point out one other thing. You wrote:
    “Spotlight treats every word as if you had added a wildcard at the end of its name—my search was really the* under* over* be* fore* ate* desktop* zoo*.”

    But it would appear that, if Spotlight finds the term “material” from searching “ate,” it’s using a wildcard not only at the end of each term, but also at the beginning. This goes a long way to explaining why Spotlight finds waaaay to many irrelevant results for my tastes.

    Good article. Stuff I didn’t know. Thanks.

  10. The thing that I like about Quicksilver that Spotlight doesn’t do is that Quicksilver learns from you. When I type “a” in Quicksilver it brings me my Applications folder because that is what I usually choose whn I type “a”, but no matter how many times I type “a” in Spotlight, the top result is Automator.
    Other Spotlight rants:
    • Why does it only have one top result. I why isn’t it even there in the window view. Several top results that LEARN what you like would be nice.
    • Why does the menu only fill HALF THE SCREEN???
    • Why can’t you turn a search item off for only the menu but not the window? If you’re only going to give me half the screen, it might as well be of what I want.
    • There need to be the ability to do advanced searches without having to resort to the Finder. I didn’t even realize the advanced metadata searches that the Finder lets you do until I tried to do a find by kind in the Finder. An advanced search menu item or keyboard shortcut that does the same thing as an advanced Finder search would let more people utilize the real power of Tiger’s metadata.

    One might note that the Spotlight “wildcard function” mention above acts just like Preview’s search.

  11. I am also getting frustrated by spotlight features. I have been trying to make changes to my address book. Now this may seem pedantic butt bear with me, it gives a good example of spotlight frustration.

    I have entries in Addressbook that I want to change from U.S.A. and U.K. to USA and UK for the Country reference.

    If I type U.K. in to the search field in Addressbook I get any entry that has both a U and a K in the addressbook record such as Karim who lives in the USA.

    The only way I have found around this is to create a Smart Group with Address Contains U.K.

    You would think Spotlight would be sensible enough to recognize “U.K.” as a search term and return entries that contain this specific string.

Leave a Reply

The Robservatory © 2018 • Privacy Policy Built from the Frontier theme