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.

Bug 31283 - Tune find highlight colors
Summary: Tune find highlight colors
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: Search (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: Milutin Kristofic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-20 19:07 UTC by Jesse Glick
Modified: 2011-07-08 14:00 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.