This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version: NetBeans IDE Dev (Build cnd-main-4371-on-101025) Java: 1.6.0_21; Java HotSpot(TM) Client VM 17.0-b16 System: Linux version 2.6.32-21-generic running on i386; UTF-8; en_US (nb) --------------------------------------- CND pack: -- add MyFile.cc to any C/C++ Project -- Navigate->Go To File -- type 'My' ==> File MyFile.cc is found (OK!) -- type 'MyF' ==> File is NOT found
See also iz190213
As far as I know the cnd has it's own GTF provider.
CND GTF provider uses name matcher returned by org.netbeans.spi.jumpto.support.NameMatcherFactory Pattern is wrong.
The NameMatcherFactory has nothing in common with parsing API. It's in the jumpto module and it was contributed by cnd team. But OK, I will fix it.
Main idea of NameMatcherFactory is: different goto must have name matcher with same behavior. In general goto provider does not interest in context details. It goes through all own items and check name by matcher. Instead goto API exposes context with different unclear methods (it seems methods are lucene centric).
>In general goto provider does not interest in context details. Yes, it's interested in it. As it can optimize the search using the entered text. >It goes through all own items and check name by matcher. Well, O(log n) is always better then O(n). Also problems with CHA and IC on polymorphic types. >Instead goto API exposes context with different unclear methods (it seemsmethods are lucene centric). The GTT provider gets Context with: getText() - text to search getProject() - project in which to do search getSearchType() - type of the query. What is lucene centric on it?
(In reply to comment #6) > >In general goto provider does not interest in context details. > Yes, it's interested in it. As it can optimize the search using the entered > text. > >It goes through all own items and check name by matcher. > Well, O(log n) is always better then O(n). Also problems with CHA and IC on > polymorphic types. I agree, but some storage does not allow O or O(log n) for all types of context. For example TreeMap allows to optimize case sensitive request by prefix only. > >Instead goto API exposes context with different unclear methods (it seemsmethods are lucene centric). > The GTT provider gets Context with: > getText() - text to search Ok, Now I see that getText() returns user typed text. It is what I want to see. It is clear. > getProject() - project in which to do search > getSearchType() - type of the query. I'd prefer control type of query. Now user cannot see what query will be performed. > What is lucene centric on it? Sorry if I hurt you.
>Sorry if I hurt you. No, it's OK. I was not just clear what is the problem. This should be easy to fix, it's only wrong regexp in the NameMatcherFactory which requires the regexp to end by \w which does not accept '.cc' because of the dot.
Fixed jet-main ce62b4bb73c8 I've changed the CamelCase pattern to end with .* as in java. I also changed the way the CC is build. The FileName added camel part after each char. For FoLi it created: F[DIGIT|LOWER]*o[DIGIT|LOWER]*L[DIGIT|LOWER]*i[LETTER]* Now it's like in java: Fo[DIGIT|LOWER]*Li*
Integrated into 'main-golden', will be available in build *201010270000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ce62b4bb73c8 User: Tomas Zezula <tzezula@netbeans.org> Log: #191347:[C/C++ pack] Navigate->'Go To File' does not find files with CamelCase