Welcome to the MacNN Forums.

CharlesS · Apr 30, 2005, 01:31 AM

Does anyone else get this one? I'm willing to accept the possibility that my index may just have been screwed up, but if someone else has got the same problem, I'm going to report it.

My intended use for Spotlight was to use it to search the HTML developer docs that are stored in /Developer/ADC Reference Library/documentation. Well, imagine my frustration when my searches for class and method names turned up the headers, but not the docs! So, I used the mdimport command, like so:

mdimport /Developer/ADC\ Reference\ Library/documentation/

and guess what? The files still didn't show up in my Spotlight search! Okay, so now I used this command:

mdimport -f /Developer/ADC\ Reference\ Library/documentation/

and it seemed to work.

This stuff wasn't blocked in the Spotlight privacy settings, so why doesn't it get indexed unless I use the -f flag?

barney ntd · Apr 30, 2005, 05:52 AM

According to page 15 of http://images.apple.com/macosx/pdf/M...otlight_TB.pdf, spotlight doesn't index HTML. Perhaps a developer opportunity?

Barney.

Geobunny · Apr 30, 2005, 09:45 AM

Is that true, barney_ntd? I just did a search and it came up with an html document as the "top hit". Will let you know about the dev docs soon, I'm currently un-installing devtools as I got a bunch of errors the first time I tried for some reason

Hi I'm Ben · Apr 30, 2005, 10:10 AM

I believe Spotlight reads HTML documents rendered, not as source code.

Geobunny · Apr 30, 2005, 10:37 AM

Damn, ran the uninstall.pl script, restarted and tried again. Same error at the same point. Any thoughts?

Apr 30 15:17:20 Mercury : BomFileError 2: No such file or directory - ///Developer/ADC Reference Library/documentation/Java/Reference/1.4.2/appledoc
Apr 30 15:17:20 Mercury : Install failed: Some files for DevDocumentation may not have been written correctly.

I know this means that the devtools probably installed properly, but as a Java developer, the Java documentation is actually quite important!! I'm wondering if that's maybe why it's turned off by default.

[Edit: Seeing it split over two lines here makes me wonder if the spaces in "ADC Reference Library" are what's throwing the installer into a hissy fit? ]

Geobunny · Apr 30, 2005, 10:42 AM

BTW CharlesS, you're right, the developer documentation does not get indexed. Very unhelpful indeed. Mind you, it was quite cool (if somewhat pointless) to see just how many times I actually use an NSArray!

CharlesS · Apr 30, 2005, 12:45 PM

Originally Posted by barney ntd

According to page 15 of http://images.apple.com/macosx/pdf/M...otlight_TB.pdf, spotlight doesn't index HTML. Perhaps a developer opportunity?

Barney.

Oh, it indexes the HTML dev docs just fine if you force it. And before I forced it, it was finding HTML files just fine, just not the ones in the developer folder.

This... I mean... WTF? Do they think no one would ever want to search through developer documentation?

TETENAL · Apr 30, 2005, 01:10 PM

Maybe the developer documentation is not indexed by Spotlight because it already is indexed and that index can be accessed with Xcode?

CharlesS · Apr 30, 2005, 01:54 PM

Originally Posted by TETENAL

Maybe the developer documentation is not indexed by Spotlight because it already is indexed and that index can be accessed with Xcode?

Yeah, but unless I'm mistaken, it always searches through the entire API docs. Suppose, say I wanted to search only the Carbon docs, or only the Cocoa docs? Spotlight has the potential to be more flexible here since theoretically I should be able to just navigate to the "Carbon" folder and type something into the Finder toolbar.

I say theoretically, because in the real world, this still doesn't seem to work. For most folders, the Finder toolbar search field seems to do a full keyword search including file contents, while in the Developer folder it only seems to do a filename search, even though I've manually indexed the folder and I can find files in there through a content search if I used the Spotlight menu in the upper-right corner.

TETENAL · Apr 30, 2005, 02:01 PM

Originally Posted by CharlesS

Yeah, but unless I'm mistaken, it always searches through the entire API docs. Suppose, say I wanted to search only the Carbon docs, or only the Cocoa docs?

You can select Carbon or Cocoa or QuickTime etc. pp. on the left side in the Xcode documentation window and it will search in that only.

CharlesS · Apr 30, 2005, 02:23 PM

Originally Posted by TETENAL

You can select Carbon or Cocoa or QuickTime etc. pp. on the left side in the Xcode documentation window and it will search in that only.

Did you actually try this before posting? Because you're wrong. Click on "Carbon" on the left hand pane and then do an API search for NSString. You'll get stuff in the Cocoa docs...

TETENAL · Apr 30, 2005, 02:27 PM

Originally Posted by CharlesS

Did you actually try this before posting?

Yes, I did. I do it all the time.

At the moment I can't check this though, but I will soon post how to do it exactly.

thefamousmred · Apr 30, 2005, 02:40 PM

Originally Posted by CharlesS

This... I mean... WTF? Do they think no one would ever want to search through developer documentation?

They think that average users won't want to search for things in the developer docs, even if they're installed. For the vast majority of users, this makes perfect sense. Therefore it's the default.

They figure developers are smart enough to index the docs on their own.

OreoCookie · Apr 30, 2005, 02:42 PM

Originally Posted by CharlesS

Did you actually try this before posting? Because you're wrong. Click on "Carbon" on the left hand pane and then do an API search for NSString. You'll get stuff in the Cocoa docs...

Cocoa and Carbon mingle more and more. So it'll find both.

Geobunny · Apr 30, 2005, 04:07 PM

Originally Posted by thefamousmred

They think that average users won't want to search for things in the developer docs, even if they're installed. For the vast majority of users, this makes perfect sense. Therefore it's the default.

They figure developers are smart enough to index the docs on their own.

Surely "the average user" won't have the developer tools installed?

CharlesS · Apr 30, 2005, 07:19 PM

Originally Posted by thefamousmred

They think that average users won't want to search for things in the developer docs, even if they're installed. For the vast majority of users, this makes perfect sense. Therefore it's the default.

They figure developers are smart enough to index the docs on their own.

You know, though, since Tiger no longer has a way to do a catalog search from the Finder, any unindexed files won't show up at all in any Finder search, even if you search for their filenames. Therefore, the files need to be indexed.

Furthermore, whatever stops Spotlight from automatically indexing the dev docs seems to be keeping the Finder search (although not the Spotlight menu) from searching their contents, as only a filename search will work from the Finder even after indexing the files.

And I agree with Geobunny; why would average users install the dev tools?

CharlesS · Apr 30, 2005, 09:21 PM

Originally Posted by OreoCookie

Cocoa and Carbon mingle more and more. So it'll find both.

Searching in Carbon for "NSString" turns up the NSStringFromClass() function. What the hell does that have to do with Carbon?

If I'm searching the Carbon docs, I only want to get Carbon docs. Non-Carbon stuff showing up in my search just means that many more garbage results. If the Spotlight Finder search worked properly, I could select the Carbon folder, search for something, and get results only from files in the Carbon folder.

scb · Apr 30, 2005, 09:41 PM

This is probably connected, but "hidden" folders like /usr and /sbin do not appear to be indexed either, and files within those folders cannot be found by a search, even when searching for invisible items. (This used to work in 10.3.)

Does anyone know what the "path filtering rules" are that are mentioned in the mdimport man page? What's the downside of using "mdimport -f /"?

OreoCookie · Apr 30, 2005, 09:58 PM

Originally Posted by CharlesS

Searching in Carbon for "NSString" turns up the NSStringFromClass() function. What the hell does that have to do with Carbon?

If I'm searching the Carbon docs, I only want to get Carbon docs. Non-Carbon stuff showing up in my search just means that many more garbage results. If the Spotlight Finder search worked properly, I could select the Carbon folder, search for something, and get results only from files in the Carbon folder.

It's all part of the HIT. For instance the OS X Carbon printing dialog leads basically to the Cocoa printing dialog. That's what I mean when I say Apple mingles them.

CharlesS · Apr 30, 2005, 10:00 PM

Okay, here's something really weird. If I click on the /Developer/ADC Reference Library/documentation and search for a keyword that's in the file contents (but not the filename) of some file in that folder, it turns up nothing. But... if I click on the /Developer folder and do the exact same search, it works!

WTF?

Originally Posted by scb

What's the downside of using "mdimport -f /"?

It would override any exclusions that you happen to have set.

edit: upon further testing, it seems that searching either at the / or /Developer finds the files. The point where it breaks is /Developer/ADC Reference Library. Searching in that folder or any subfolder of it causes the content search to fail. I'm going to try mdimport -f'ing /Developer/ADC Reference Library instead of /Developer/ADC Reference Library/documentation and see if that makes a difference. I'll report back later...

CharlesS · Apr 30, 2005, 10:58 PM

And it made no difference. Even after mdimport -f'ing /Developer/ADC Reference Library, searching from that folder or any of its subfolders doesn't do the content search.

And I think I've found the file that causes /Developer/ADC Reference Library - unfortunately, it's the /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Support/mds binary itself - it's hard-coded in. That means changing it wouldn't be a simple plist hack...