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.
You request exactly opposite than just recently fixed enhancement: http://www.netbeans.org/issues/show_bug.cgi?id=30187,
if we implement prefix search, we can reopen that one...
Allowing regexps would help it a little, IMO...
maybe a comandline switch that would define the default behavior would help? old x new.
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.
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).
> 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...
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.
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.
Reopening to allow NetFIX team implement this according to the latest agreement. Issue was added to the pool . Module owner please speak up if you disagree. Thanks!
There is no regression in the platform/explorer modules. Moving to general IDE component.
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.
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.
If you think so, Jesse: I've created a separate enhancement for platform/explorer and make this projectui bug depend on it.
There's no purpose in this being a separate item.
*** This bug has been marked as a duplicate of bug 184321 ***
Actually easier to retain this as the original issue.
*** Bug 184321 has been marked as a duplicate of this bug. ***
I'd like to NetFIX  this bug. Is it possible?  http://wiki.netbeans.org/NetFIX
Sure. Do you plan to implement the suggestion in comment #6, or something else?
Yes. Suggestion in comment #6 looks better. I will go ahead with this solution for the fix.
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 http://bits.netbeans.org/dev/javadoc/org-openide-explorer/org/openide/explorer/view/TreeView.html#setUseSubstringInQuickSearch(boolean) 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 ?
Rather you can add new setter to turn your behavior on.
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.
Fixed. Please review the attached patch. The default behavior of the substring search has been changed so that the prefix matches will come first.
Created attachment 113144 [details]
fix for 153331
Jesse, can you please review the patch and integrate it? Thanks.
[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
Then this will undo the enhancement done for bug 30187. Will it violate that enhancement?
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.)
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.
(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.
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.
Created attachment 113801 [details]
Not FIXED until committed to trunk.
(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!
Integrated into 'main-golden'
Log: #153331: give preference to prefix matches in Quick Search.