Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 153331 - [68cat] Give preference to prefix matches in Quick Search
[68cat] Give preference to prefix matches in Quick Search
Product: platform
Classification: Unclassified
Component: Explorer
All All
: P3 (vote)
: 7.2
Assigned To: Jesse Glick
: 184321 (view as bug list)
Depends on:
Blocks: 30187
  Show dependency treegraph
Reported: 2008-11-17 18:12 UTC by matthies
Modified: 2011-12-08 12:13 UTC (History)
5 users (show)

See Also:

fix for 153331 (10.53 KB, patch)
2011-11-12 09:57 UTC, remould
Details | Diff
Patch v2 (18.87 KB, patch)
2011-12-04 16:50 UTC, remould
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description matthies 2008-11-17 18:12:13 UTC
The behavior of Quick Search in the Files view (typing characters to jump to a file) appears to have been changed from 
NetBeans 6.1. Previously, the typed characters only matched a prefix of the file name. Now they match anywhere in the 
file name. In folders with many files/classes this tends to make Quick Search useless.

For example,  I have a package with a class "Validator" and many sub-classes "<SomethingOrOther>Validator". Keyboard 
focus is close to the top of the folder, and I type "v" or "val" to move to the "Validator" class. But this doesn't 
work because all the subclasses do match as well. There is no fast way to move to the "Validator" class using the 
keyboard any more.

In other words, quick prefix jumping is gone. It would be great to get it back. In fact, I would be most happy with 
just a single-character or multi-character timeout prefix jump like for example in Windows Explorer.
Comment 1 Petr Dvorak 2008-11-18 13:41:51 UTC
You request exactly opposite than just recently fixed enhancement:,
if we implement prefix search, we can reopen that one...

Allowing regexps would help it a little, IMO...
Comment 2 Lukas Hasik 2008-11-18 13:53:40 UTC
maybe a comandline switch that would define the default behavior would help? old x new.
Comment 3 matthies 2008-11-18 14:14:18 UTC
Well, it's clear that these are conflicting requirements. My point is this: There is a need to be able to navigate 
within a folder with a minimum of key strokes. In a folder with 40+ items, it's tedious to have to press cursor-up or 
cursur-down dozens of times to navigate to an item (even with key repeat). To that purpose GUIs normally provide the 
functionality that typing a character jumps to the next item starting with that character (for example in Windows list 
boxes, dropdown boxes and menus without accelerator keys), or that typing a sequence of characters within some timeout 
jumps to the next item starting with that sequence (Windows Explorer). This basically gives you a reasonable O(log(n)) 
navigation speed, so to speak, instead of a tedious O(n). NetBeans's previous Quick Search, while not exactly the same 
thing, was close enough to fulfill that purpose. The new Quick Search behavior however fails to do so, as it generally 
matches more items, often too many, and the items it matches are not necessarily adjacent (as with prefix search), but 
can be all over the place. It becomes difficult to determine a search term that only matches the item one wants to 
navigate to (or an item close to it). Sometimes even typing the full item name doesn't help much if it happens to be 
part of the names of other items. The new behavior constitutes a significant degradation of keyboard navigability in 
the affected tree views.
Comment 4 matthies 2008-11-18 14:19:35 UTC
How about the following: Implement a prefix navigation as in Windows Explorer (this would be an new enhancement of 
course), and to invoke Quick Search (with the new behavior) require a keyboard shortcut, maybe "/" like in FireFox 
(assuming that items starting in "/" are impossible or very rare).
Comment 5 Petr Dvorak 2008-11-18 14:36:20 UTC
> How about the following...

This might work quite nicely actually - typing would start the "prefix search", pressing '/' would display field for
"quick search"... the question is if anybody will figure the "quick search" shortcut out if it is implemented this way...
Comment 6 t_h 2008-11-18 15:41:08 UTC
What about searching all prefix matches first and then substring matches? I mean substring match would be selected only
if you cycle through all prefix matches (via up/down) or if no prefix match exists.
Comment 7 matthies 2009-08-20 13:47:58 UTC
Updated TM.
Comment 8 Jaroslav Tulach 2010-04-01 21:21:14 UTC
Changing the current behavior now would be again a regression. Won't fix, unless you want to provide a patch with a property on TreeView choosing which quick search style use.
Comment 9 Jiri Kovalsky 2010-04-09 13:03:56 UTC
Reopening to allow NetFIX team implement this according to the latest agreement. Issue was added to the pool [1]. Module owner please speak up if you disagree. Thanks!

Comment 10 Jaroslav Tulach 2010-04-09 18:11:16 UTC
There is no regression in the platform/explorer modules. Moving to general IDE component.
Comment 11 Jaroslav Tulach 2010-04-15 07:20:44 UTC
There is no regression in platform/explorer. There is
which defaults to original behavior and it is up to individual views to choose what kind of search want to use.
Comment 12 Jesse Glick 2010-04-15 17:41:28 UTC
I think comment #6 (when the flag is true) is the most promising compromise solution, that would work well in most cases without the user needing to know to do anything special.
Comment 13 Jaroslav Tulach 2010-04-16 06:16:34 UTC
If you think so, Jesse: I've created a separate enhancement for platform/explorer and make this projectui bug depend on it.
Comment 14 Jesse Glick 2010-04-16 13:46:34 UTC
There's no purpose in this being a separate item.

*** This bug has been marked as a duplicate of bug 184321 ***
Comment 15 Jesse Glick 2010-04-16 13:50:01 UTC
Actually easier to retain this as the original issue.
Comment 16 Jesse Glick 2010-04-16 13:50:08 UTC
*** Bug 184321 has been marked as a duplicate of this bug. ***
Comment 17 remould 2011-11-03 17:07:48 UTC
I'd like to NetFIX [1] this bug. Is it possible? [1]
Comment 18 Jesse Glick 2011-11-03 21:09:39 UTC
Sure. Do you plan to implement the suggestion in comment #6, or something else?
Comment 19 remould 2011-11-05 07:23:54 UTC
Yes. Suggestion in comment #6 looks better. I will go ahead with this solution for the fix.
Comment 20 remould 2011-11-06 07:33:12 UTC
The proposed solution in comment #6 will result in changing the default behaviour of the quick search, so that it will use both prefix and substring search. In this case the method will no longer be used and might have to deprecate it.

Currently the quick search works only by prefix or substring, not by both. If I implement the quick search with both prefix and substring search, then using setUseSubstringInQuickSearch method wont make any sense. So is it ok to deprecate this ?
Comment 21 Jaroslav Tulach 2011-11-07 08:02:12 UTC
Rather you can add new setter to turn your behavior on.
Comment 22 remould 2011-11-09 06:05:25 UTC
If I add a setter method for turning this on, then all dependent modules need to be updated to enable this behavior. Otherwise the substring search will be used.
Comment 23 remould 2011-11-12 09:56:25 UTC
Fixed. Please review the attached patch. The default behavior of the substring search has been changed so that the prefix matches will come first.
Comment 24 remould 2011-11-12 09:57:14 UTC
Created attachment 113144 [details]
fix for 153331
Comment 25 Jiri Kovalsky 2011-11-14 10:27:10 UTC
Jesse, can you please review the patch and integrate it? Thanks.
Comment 26 Jesse Glick 2011-11-23 16:15:50 UTC
[JG01] I would recommend just deprecating (*) setUseSubstringInQuickSearch as in comment #20 and making it a no-op (deleting quickSearchUsingSubstring and simplifying the code accordingly). I do not see any reason to believe that some users of TreeView would not want the newly implemented behavior; this can just be considered a quality of implementation issue and need not be exposed in the API. TreeViewQuickSearchTest could be correspondingly simplified. Could also remove the calls from:


and for bonus points create openide.explorer/src/META-INF/upgrade/TreeView.hint following the model of hints in openide.filesystems etc.

(*) @Deprecated, plus @deprecated in Javadoc with explanation
Comment 27 remould 2011-11-26 16:49:07 UTC
Then this will undo the enhancement done for bug 30187. Will it violate that enhancement?
Comment 28 Jesse Glick 2011-11-30 14:00:51 UTC
I think it would improve that enhancement, not violate it - the user would be able to use either prefix or infix search according to whim.

(In cases where some nodes have the given search text as a prefix, and others do not but do have it as an infix, the behavior might be slightly confusing since you could jump backwards when transitioning from prefix to infix. But I bet this is relatively uncommon and it should still work decently.)
Comment 29 remould 2011-12-01 09:53:41 UTC
Since this and bug 30187 are conflicting enhancements I'm a bit confused. Your suggestion is to deprecate setUseSubstringInQuickSearch() method and keep the infix searching behavior by default? Correct me if I'm wrong.
Comment 30 Jesse Glick 2011-12-01 15:14:07 UTC
(In reply to comment #29)
> Since this and bug 30187 are conflicting enhancements

I think this rather supersedes #30187. Why would it be conflicting?

> Your suggestion is to deprecate setUseSubstringInQuickSearch()


> and keep the infix searching behavior by default?

Yes, but prioritized after prefix searches, as your patch already does. Basically to just make the smarter search active unconditionally, since I know of no reason why a GUI employing a tree view would wish to specifically suppress infix search matches even when there is no prefix match; this would not seem to offer any user benefit. setUseSubstringInQuickSearch was originally added to the API because without your patch a GUI had to _choose_ which kind of search to allow and it was thought that for some use cases the switch from prefix to infix could be a functional regression.
Comment 31 remould 2011-12-04 16:50:23 UTC
Patch updated with Jesse's suggestions. setUseSubstringInQuickSearch() method is deprecated and removed calls from classes specified in comment #26. Also please review the TreeView.hint file as I'm not sure whether I have done it in the way that is expected.
Comment 32 remould 2011-12-04 16:50:38 UTC
Created attachment 113801 [details]
Patch v2
Comment 33 Jesse Glick 2011-12-05 15:21:16 UTC
Not FIXED until committed to trunk.
Comment 34 Jesse Glick 2011-12-07 23:53:07 UTC
(In reply to comment #31)
> please review the TreeView.hint file

I tried to write one, but attempting to use it gave me an error (bug #206116) so I gave up on it.

Committed as core-main #af97c8367428 and trivial add-on edits as core-main #1856117be39f. Thanks!
Comment 35 Quality Engineering 2011-12-08 12:13:11 UTC
Integrated into 'main-golden'
Log: #153331: give preference to prefix matches in Quick Search.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo