Impacts KB navigability, e.g. of large search results.

This shows that NextOutJumpAction as a global one is not working fine.

I suggest to make it really context aware, i.e. override its
getActionMapKey, and that provided key to use in the output component
actionMap to delegate to such action which will work according that
component context (i.e. in search resutls make what does its performer
and in compiler what does its performer).

Look at http://openide.netbeans.org/proposals/actions/impl.html#callback

I'm not much in it, so if there are some problems with it, please let
me know.

Peter, I don't think that can work. It is not enough to bind these
keys in the output window. They can be called from the editor window
too and expected to work with the last-selected output window.

See also comments in issue #30535. That issue suggests a possible need
for a more general, and API-accessible, solution to the prev/next jump
action design. However *this* issue can be solved w/o any API change,
since I am referring only to the real Output Window: Search Results
just uses IOProvider etc. as usual, meaning the component is
implemented in core/output and can know what the current output window
tab is.

Possible solution to *both* issues:

1. Some API (openide/io?) will define the action map names "next-link"
and "previous-link" (e.g.); it need not do anything else except
document them

2. Global KB bindings for F12 & S-F12 changed to be bindings for these
names, like an input map (is this possible yet?!)

3. OutputTabTerm will put something in its TopComponent lookup that
will be its list of known hyperlinks - exact content acc. to private
impl. in core/output 

4. The actions in core/output will *not* be CallbackSystemAction's;
just plain AbstractAction's, I guess, implementing ContextAwareAction;
they will ask the context for the stuff that OutputTabTerm put into
its lookup, and jump around between links in that tab only

5. OutputTabTerm will bind "next-link" and "previous-link" in its
action map to these actions

6. Task List suggestions view (etc.) will bind these action names to
its own analogous actions

7. CloneableEditor will bind these action names to proxies which
listen to changes in the active top component, updating their
delegates to be that of the last top component to be activated which
had bindings for their own names

Then pressing F12 & S-F12 on any output-type component will always
navigate within it. These keys from the editor will work with the last
selected output-type component.

The only part I am not sure about is step 2. Currently shortcuts are
bound directly to action implementations. We need them bound instead
to action names, like Swing input maps do. In this case we can
probably hack around it by binding them to special proxy actions which
somehow find the focus owner active at the time the action was invoked
(acc. to the action event? does this work?), look up the real action
according to the action map of that component, and delegate to it with
the same action event and action context.

Variant: collapse #2 & #7, so that the global KB shortcut bindings
(could be defined in *any* module, but probably core/output) are just
bound to proxy actions (maybe two instances of the same class). These
take their action event and obtain the focus owner from it. (Details
TBD) If that owner provides a binding for the action in its action
map, it is run directly, with context taken from the closest enclosing
Lookup.Provider in the component hierarchy as usual. If there is no
such binding available, then the proxy action has also been keeping a
listener active on TopComponent's, waiting for selection of a
component with a binding for its own name; if one appears, it keeps a
weak reference to that component. When next invoked on a component
with no binding of its own, it goes back to the last output component
(if it still exists, is open, is showing, etc.), asks it again for its
binding, and runs it (again with the usual action context taken from
TC.lookup).

More or less the same effect, but has the advantage that you continue
to define the physical KB shortcut in one place only, making user
customizations of this shortcut easier.

Probably want to write this proxy action class as neutrally as
possible and just create two instances parametrized by action name
("next-link" etc.) using methodvalue in core/output layer. That way if
this kind of thing works well, we could easily make it into an SPI for
some future Actions rewrite - a general proxy action that operates on
either the selected component, if possible, else on the last selected
top component to define it.

Yes, I think the 'Proxy action'-solution from Jesses last comment is
the right way for this kind of problem.


Well, so to not forget about the support ProxyAction class I create a
task for it.
When also another Action support clases (NodeAction, CookieAction)
will be written it should be between them.

Of course "ProxyAction" is not a great name for such a thing, since it
has more specific behavior than just proxying. No suggestions re. name
for now.

Reassigning to Marek, new owner of output window and help system

The core team has not been responsible for terminal emulator for long time, so
reassigne all opened issues to responsible person.

moving opened bugs on terminal emulator to terminalemulator/code as the core
component will be closed soon - http://wiki.netbeans.org/CoreQEIssuezillaAndModules

This all looks like water under the bridge.
For one thing F12 is no longer a standard NB accelerator.
For another output windows was rewritten.

The recently introduced terminal based IO _does_ have issues with
handling global NB accelerators (see bug #185483) but that
doesn't seem to be the issue here.