Community
Participate
Working Groups
Build 20011127 Due to bug 6423 fix, the API SearchEngine.search(IWorkspace, String, int, int, IJavaSearchScope, IJavaSearchResultCollector) is now performing a case insensitive search (more intuitive). However, the UI page should offer a checkbox for case sensitivity, and rather use the following call to trigger the search: SearchEngine.search(workspace, createSearchPattern(patternString, searchFor, limitTo, caseSensitiveFlag), scope, resultCollector);
UI will add a checkbox for a case sensitive search. However, changing the API contract to make SearchEngine.search is a breaking API change that we cannot do now. I strongly disagree that an insensitive search is more intuitive. The UI should deal with the default setting of case sensitive search, this should not be done at the API level. However, the current API doesn't allow the UI to do so: SearchEngine.search(IWorkspace, IJavaElement, int, IJavaSearchScope) doesn't provide support for setting whether the search should be done in a case insensitive way. Proposal: - change the default back to the old one (case sensistive is the default) - add support for defining case sensitivity consistently in the API Once this is in place the UI will add the checkbox and offer a case insensitive Java search. The default will be case sensisitive but the setting will be remembered. Moving back to Java Core
Add checkbox with "case-sensitive" as default. The state of this checkbox must be be remembered. Note: Text search checkbox should be enhanced accordingly
It doesn't make sense to search references to an IJavaElement in a case insensitive way. This is especially true when the user starts the search from the context menu (i.e. in the outline, in the package view etc.) When the user starts the search from the search dialog, she doesn't have the impression of doing a search on an IJavaElement any more, but on a string pattern (since this is what is shown in the dialog.) Having said that, I think the existing API is sufficient for the UI: when the user brings up the search dialog with an IJavaElement selected, if she doesn't do any change, then SearchEngine.search(IWorkspace, IJavaElement, int, IJavaSearchScope) can be used (as it is now). If she makes any change (including unchecking the "case-sensitive" checkbox), then SearchEngine.search (workspace, createSearchPattern(patternString, searchFor, limitTo, caseSensitiveFlag), scope, resultCollector) should be used.
Forgot to CC you. Please see my previous comment.
Switching case-sensitivity should not impact the accuracy. If I have to convert form a IJavaElement based search to string based search I will lose information. Why should a user of the Search API not be allowed to use an IJavaElement (e.g. method "close" from the Outline or retrieved via code resolve) as input to a case-insensitive search i.e. why not offer such an option? Why does the client have to deal with the transformation into a string? The API change was not commented. If the API is changed then I would also expect that search for declarations of method "x.close()" (= IJavaElement) would return methods like "Y.ClOse()" - just to be in synch.
API reverted to its old behavior. Moving back to JUI for disposal.
when the text input for the field comes from an IJavaElement then the case sensitive box should be disabled (but preserve its state). It doesn't make sense to do an case insensitive search in this case. The check box is enabled as soon as the user starts editing.
Yep, with this in place the user will then even be able to tell whether a string or the Java element is used to perform the search.
Fixed Available in builds > 20011211
