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.
|Summary:||Tune find highlight colors|
|Product:||editor||Reporter:||Jesse Glick <jglick>|
|Component:||Search||Assignee:||Milutin Kristofic <mkristofic>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
Description Jesse Glick 2003-02-20 19:07:17 UTC
[dev feb 19] If you are in a file with many lines exceeding the size of the editor window, so that there are long horizontal scrollbars, and then press Ctrl-H to find and replace text strings, it can often happen that the currently selected strings is off-screen! So you cannot see what you are about to replace. Another longstanding complaint of mine is that while replacing text, all matches are highlighted in yellow, except for the current one which is highlighted in grey (or sometimes purple if you have not yet pressed Enter to jump to the next one??). This is extremely confusing IMHO. I have used this dialog for years, yet I still have trouble remembering what it is I am about to replace. I also recall being confused about the fact that the button "Find" in this dialog does what most people would expect to be done by a button labelled "Skip" - except the first time, since for some reason you have to press it once to do anything! I think the UI of this dialog should be cleaned up considerably, especially for keyboard usage. What I expect: 1. Press Ctrl-H to open the dialog. (Would be nicest if it did *not* open directly over the editor window, as this makes it pretty much useless until you move it!) 2. Enter the "from" text. 3. Press Enter (not Tab!) to move to the "to" field. 4. Enter the "to" text. 5. The first match would already be selected (incremental during step #2). Should be highlighted in a nice bright color, not grey; nothing else highlighted; must be visible on-screen. 6. For that and all subsequent matches, should be able to press some simple keystroke (mnemonic?) to either Skip or Replace. 7. When all matches have been scanned, dialog should probably close. I use search-and-replace in Emacs all the time, and it is easy and fast. It is so much harder in NetBeans that when I have to do it, I often just switch to Emacs, open the file, do the s-and-r, save, then go back to NetBeans.
Comment 1 Martin Roskanin 2003-02-28 15:48:04 UTC
At this time only P1s and P2s are allowed to be integrated into newly created branch "release35". http://www.netbeans.org/servlets/ReadMsg?msgId=475395&listName=nbdev Changing target milestone to 4.0
Comment 2 pfelenda 2004-03-04 12:57:05 UTC
I think that this should be fixed in next release. The dialog is not usable for normal user.
Comment 3 psuk 2004-03-23 18:01:35 UTC
Changing subcomponent to "search"
Comment 4 Roman Strobl 2005-01-10 13:14:46 UTC
Changed target milestone to TBD.
Comment 5 Miloslav Metelka 2005-02-02 09:49:28 UTC
Adding Ruda to cc. The first issue (related to horizontal scrolling) - is it still a problem? I was unable to reproduce the behavior. Regarding yellow highlighting - I share your opinion. Not sure whether a simple changing of the highlight color to something less attractive for eyes (and changing the selection background color to be more noticeable) will suffice or whether we need to think about a completely different functioning. Rudo, could you try to experiment with the colors and also check other editors how do they solve this problem? Thanks. Regarding the other things: - IMHO it would be good if pressing Enter when being located in the "Find What" field would find the first occurrence and jump to "Replace With" field. - Not sure whether we should add a "Skip" button - the "Find" button in fact does the same though the "Skip" could be more appropriate (could we just change the "Find" to "Skip"??)
Comment 6 Martin Roskanin 2005-03-18 08:26:25 UTC
It is longtime issue. Several problems were redesigned, fixed. Several persist. I have done a recapitulation of the current state. It seems to me that there is only one defect. After fixing it I would change the issue to enhancement to resolve open issues (Task for Ruda). If you do not agree with bellow comment, please speak. Thanks. FYI - Find & Replace dialog was redesigned in accordance with UI spec: http://ui.netbeans.org/docs/ui/editor/find_dialog/find_dialog.html - I cannot reproduce off-screen selection also - Find versus skip - already solved AD 1: Initial dialog open position is mid screen, during further invocations it remembers last location AD 3: I don't agree. Enter is a key that is bound to default button - find. Tab is a standard key for focus traversing. (Using your scenario it is not very convenient to use replace dialog for simple find operation) AD 6: Solved AD 7: IMHO it is too heuristic and can cofuse user. There is Close button, its mnemonic and ESC key for that. ---------------------------------------- current defect: AD 5: "nothing else highlighted" - yes, the previuos yellow highlighting should gone after first incremental find result is selected. Selection grey color is used for incremental search in accordance with ui spec. Open issues (enhancements): - higlight color - incremental search color
Comment 7 Martin Roskanin 2005-03-23 08:35:58 UTC
fixed in [maintrunk] yellow highlighting hidden after first incremental find result is selected /cvs/editor/libsrc/org/netbeans/editor/FindSupport.java,v <-- FindSupport.java new revision: 1.72; previous revision: 1.71 Changing to enhancement
Comment 8 Jesse Glick 2005-04-06 19:36:37 UTC
I guess. Maybe just the whole design of the dialog is unpleasant for me - I still find Emacs' UI for this much faster and less confusing: I want to enter text to search for (in an area of the editor window, *not* a dialog), optionally text to replace, then be prompted for each instance and say either yes or no. However other GUI apps seem to have a similar UI, for better or for worse (mostly worse), so I will drop it. Another note I don't think I mentioned before: the current Find dialog will sometimes cover the text it is finding (or about to replace), so you really need to move it far away (with the mouse) in order to use it in practice. When the editor window uses up the whole screen, sometimes you have to keep on moving it around as you go through a document.
Comment 9 _ gtzabari 2011-07-08 14:00:41 UTC
Microsoft Word has a nice feature that moves the search dialog away if happens to overlap with the search results in the editor.