I should note that there were no changes in the Ruby area between those changesets, and while debugging this it did 
seem like the problem is in indexing and not in Ruby. Let me know if you need more info..

"... if that helps at all" - Well, it does not much. Please try to find out what _exactly_ is happening and then when
you are sure that the problem is in indexing or CSL please reassign to relevant editor category. Btw. d4549231ce0de is
not even in main-silver. I'm sorry to push this back, but I simply can't investigate every problem that seems vaguely
related to indexing. Thanks for understanding

Well, I already spent several hours debugging this and had a reason to file this against editor in the first place.

The changesets are from web-main; any recent changeset from main-silver will do (e.g. 6d2d7a349737). hg history -r 
d57bc4d3311e:6d2d7a349737 lets you see the changes between those changesets. Reverting to d57bc4d3311e and building the 
parsing.api module again resolves the issue (w/o rebuilding other modules).

I guess I'll continue debugging.

The best I can tell is that in QuerySupport:318 cacheFolder.getFileObject(indexerFolder) returns always null, hence 
nothing gets put to the indexes map. There is only one cache folder with ruby/9 (when starting with a clean userdir and 
following the steps I posted), and that isn't mapped to any of the roots passed to QS (whereas in d57bc4d3311e with the 
same args it finds several index folders). I don't know enough about how the indexing is supposed to work to tell what 
that means (if anything) or to go further than that. I think you have to continue from here; I wish I could help you 
more but I really don't have the cycles to spend on digging into the indexing impl. Besides, as I wrote and as you can 
see from the hg history, there are *no* changes in the ruby areas between the changesets, so I don't understand why I 
should have the burden of proving that the regression is not in ruby/editing -- I think it's the other way round.

Thanks a lot Erno, I'll take it from here. And sorry for forcing you to debug this for several more hours. The
additional info is very useful, because I can now start looking at a specific place in our code.

Thanks Vito, and let me know if you have any questions about the ruby stuff.

Marking as regression and leaving to Vita whether it is P1. I think it is more like P2 but as it IMHO should be fixed
before beta it doesn't make much difference whether we have it as P1 or P2.

I made this a P1 since the Ruby IDE is effectively unusable until this gets fixed (who needs an IDE without CC, and 
it's not just CC since it is a problem with the index) and it's blocking me from my work. If it helps, I can sit down 
with Vita and debug this through once we're all back at the office (on Tue I suppose).

I'm sorry for all the troubles. It should work again. http://hg.netbeans.org/jet-main/rev/f0a640024b8a

Integrated into 'main-golden', will be available in build *200904121401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/f0a640024b8a
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #162369 - apparently there is no reliable way of determining whether a mimetype has Parser or EmbeddingProvider registered; let's just filter out some well known mimetypes (eg images, zip, jar, etc) and leave the rest for ParserManager, which will simply return null Parser.Result for any file that has no Parser registered

Thanks a lot for the quick fix, works fine now.