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.
There are two search fields in the current implementation of the keymap panel, while the UI specification defines just one, multifunctional, field. This field should work for regular strings when user starts typing a string and for shortcuts when a functional key is hit when a focus is in this field. UI specification: http://ui.netbeans.org/docs/ui/keymap_option_panel/
With all the respect to the later parts of the analysis, the evaluation of IDEA + Eclipse solutions for search is not correct, and so I believe the conclusion proposed to be applied in NetBeans is also not good. IntelliJ, in fact, uses search box for action names only. The tiny icons to the right of the textfield open a modeless popup with an additional text field for shortcut-based searches. While Eclipse works as presented, it's important to note that Eclipse's usability is quite bad - the user must type modifier combination *exactly* as shown, that is "Shift+Ctrl" finds a shortcut, while "Ctrl+Shift" does not. It's easy to mistype or swap the modifiers without assistance of the text field. The implementation shoudl 'normalize' the shortcut first, which is not done in Eclipse. Also note that the textfield cannot assist the user with capturing keys and presenting the key description, since it cannot be determined whether the user pressed Ctrl+Shift+LEFT in order to move the cursor back a word and correct it, or the user really intends to search for Ctrl+Shift+LEFT. Therefore I think that we need to have 2 input boxes, as done IntelliJ. I am open to suggestions regarding positioning the boxes, or maybe hiding one (the less important one) as done in IntelliJ, if it improves appearance of the Options dialog. Marking as INVALID - Petr if you see a value in rearranging the search boxes, please reopen.
> Also note that the textfield cannot assist the user with capturing keys and > presenting the key description, since it cannot be determined whether the user > pressed Ctrl+Shift+LEFT in order to move the cursor back a word and correct it, > or the user really intends to search for Ctrl+Shift+LEFT. This is actually the key point IMHO. The fact that a unified textfield would have to use unreliable heuristics to guess whether the typed content is meant to be the shortcut to be found or just a shortcut to edit the search string - this would be a serious usability problem. Thus I vote against it as well.