#147 Incremental/Hyper search and search bar patches
- Small detail: When no word is selected, the curent caret word is searched automatically. But the word is *selected* and *then* grabbed. Why not just use a getWord() method in TextArea.java instead to grab the word without selecting it? This small detail got to me because automatic selection of the caret word causes the caret to move from original position to the end of the word, which can be annoying. The getWord() method would be exactly like the selectWord() method in TextArea.java, except for the selection code (last few lines in the method) replaced with this single line:
return getText(wordStart, wordEnd-wordStart);
Then in View.java, isntead of having
textArea.selectWord();
text = textArea.getSelectedText();
we would have just text = textArea.getWord();
--------------------------------------------
- Another small detail: When incr/hyper search *bar* is used instead of search for *word*, the text in the bar is blanked, so the user can type there on search phrase. Why would it hurt to, instead of blanking the text in the search bar, just have the current caret word be automatically placed as the search term? The only difference between search bar and search word this modification would make is that the search would not happen automatically for search bar, whereas it *would* happen automatically for search word. This just requires moving the "if(word){" lines in the quickIncr/HyperSearch methods View.java a couple lines down, so that the word-grabbing is excluded from the if condition.
--------------------------------------------
- A bug?: There is a "FocusHandler" inner class in SearchBar.java, but it is *never* added as a focusListener to the search bar in the code (just need find.addFocusListener(new FocusHandler()); ). The current FocusHandler simply adds the entered text in the searchbar to the search history when the focus is lost.
But aside that, why not add an autohide option for the search bar? This code would also go in the FocusHandler's focusLost method, and it took me a while to figure out a solution. The catch was that when the drop-down list was selected from the searchbar, that would also count as the textfield in the searchbar losing focus, so the searchbar would hide itself, which is obviously not good! This is my solution to the problem, which works just fine, but there might possibly be a better one out there:
(1) In HistorySearchField.java, add the following method:
public HistoryText getController(){
return controller;
}
(2) In HistoryText.java, add the following method:
public boolean isPopupMenu(Component comp){
return popup==null? false : popup.getRootPane() == comp;
}
(3) In SearchBar.java. add the following in the focusLost() method:
if(!find.getController().isPopupMenu(e.getOppositeComponent())){
view.removeToolBar(SearchBar.this);
}
Logged In: YES
user_id=1486645
Originator: NO
Much stuff ;-)
1. Regarding invoking "Incremental Search for Word":
When the next occurence of the searched word is found, it will be selected and the caret will be moved anyway. So does it really matter, that the word at the caret is selected before the search is started?
2. Regarding invoking "Incremental Search Bar":
If this Feature would work as documented, the *selected* text would be placed in the search string field. This would be good so (it's also the behavior of the normal search dialog).
See bug #1725202
3. Regarding focus and autohide option:
When doing a hypersearch, the bar is hidden automatically when the search is done. Otherwise the bar is needed for doing "incremental" jumping. It's perfect as it is, isn't it? :-)
svn diff for the searchbar patch
Logged In: YES
user_id=1948726
Originator: YES
1. I don't know why it was bothering me before, but yes, this issue doesn't make sense even to me know. Croos out number 1.
2. I guess it's already being/been worked on.
3. There is still room for work on this one. Firstly, there's no question that there exists a dead-code FocusHandler in SearchBar.java, it is never added to be used by any componenet (i.e. the searchbar). As for hiding the bar, let's say currently the bar isn't showing. Then you do incremental search for word or incremental search bar, and it comes up. Well, when you're done doing the incremental search, I think it should just go away again instead of having to click the 'x' on the right of it, not just for hypersearch but for incremental search as well. Of course it is needed for incremental jumping as the word is being typed, but it's not needed *after* that. And even if you have typed in the word but are just looking for more ocurrences by hitting "Enter", it will still be there. It will only hide it self when it looses focus, which indicates that it is no longer in use. I've attached the patches for these two things. Again, the auto-hide solution I suggest doesn't appear to me the cleanest one, but it's all I can come up with.
File Added: searchbar.patch
Logged In: YES
user_id=935841
Originator: NO
Please also see bug # 1887293
This fix is not 100% correct. If I have "always show incremental search bar" then I never want it to disappear.
At the moment, it does.
Would you mind testing further and submitting an updated patch that also addresses 1887293?
Then I'll accept the patch.
Logged In: YES
user_id=935841
Originator: NO
setting status rejected until the patch is updated.
Logged In: YES
user_id=935841
Originator: NO
Actually, it turns out jedit-Patches-1894235 fixes the problem, and I just applied it, and it seems to address 3 for you too.
Please test it out.