As you browse through the message window ( ant, compiler or other output) you
want to search and navigate using the same keys that you use with the editor.
Therefore, if Editor search key (or any other relevant key for that matter) is
remapped to F5 it should also work in the message window. Presently this is not
the case.
This is a nuisance because you get used to the editor remapped keys and
subconciously use it in the message pane, only to be frustrated each time.
This happens a number of times in your day to day work, please treat as high
priority.

A patch with fix attached.
Keymap Options API is now used to retrieve shortcuts for editor actions that can be reused in output window (Find, Find Next, Copy, Paste, Select all, ...) and to create a new KeymapManager.
Jesse, Fanis, please, is this solution correct? It is quite complicated, but I couldn’t find any better way to reuse shortcuts already defined for editor actions.
Fanis, can I please add a new friend module to Keymap Options API?
Petr, can you please approve this UI change?
Several hard-coded key shortcuts are now customizable in Tools -> Options -> Keymap, category Output Window. Default shortcuts for new keymap actions are equal to formerly hard-coded shortcuts.

I do not know much about options.keymap and editor keybindings in general; you need a review from someone on the editor team. The proposed patch does feel too complicated, especially the copying of editor.settings.storage.spi.support.StorageSupport. Possibly we need a generalized version of options.keymap which is designed to manage keybindings from multiple types of windows; currently there are just two kinds of bindings: global and editor. I doubt this is a candidate for fixing in 7.2 past feature freeze.

Re. storage - this is 3rd form :) in addition to .instance file-based (layer provider), and editor's keybinding XML configurations. Maybe it's really time to unify those in the keymap module. There could be other users as well (navigator, and even popup windows like call hierarchy).
re. the patch
[SD01] since it's the ShortcutsFinder implementation which uses "nice" string representation for shortcut (unlike Utilities.keyToString), I would be in favour to make a supplemental interface in keymap.options that would map String[] to KeyStroke[] - implementation is already in keymap options module & output tab could use it.

Thank you for your comments.
> I doubt this is a candidate for fixing in 7.2 past feature freeze.
I'll postpone fixing it.
> Maybe it's really time to unify those in the keymap module
I think this module is quite a good place, as it can easily provide custom shortcuts for currently selected keymap profile.
> I would be in favour to make a supplemental interface in keymap.options that
> would map String[] to KeyStroke[]
I agree.
I would also like to have a standard way to select the most appropriate shortcut to be shown in menus (e.g. not to show FIND key on platforms where FIND key is not usually present, but to show Ctrl+F alternative shortcut instead).

Created attachment 122839[details]
Patch
Updated Patch
Class org.netbeans.modules.options.keymap.Utils (private) renamed to
org.netbeans.core.options.keymap.api.KeyStrokeUtils (friend private).
Added method getKeyStrokesForAction.
There is also new method refreshActionCache and some changes in KeymapViewModel. Without these changes, outdated keystrokes are returned. It is a bad practice to refresh actions before reading keystrokes, but I was not able to find a better way to retrieve current data. Please, do you have some idea how to fix this?
Svata, could you please review the changes?