Created attachment 94302 [details]
Raw API change

Not fully finished API change that makes UndoAction and RedoAction context aware, introduces new UndoRedo.Provider interface, retrofits TopComponent to implement it and changes CloneableEditorSupport to implement it too. This shall ensure that one can

DataObject obj = DataObject.find(...);
action = undoAction.createContextAware(obj.getLookup());

associate undo or redo action with any object providing CloneableEditorSupport.

I will polish the patch and integrate tomorrow.

Created attachment 95515 [details]
The new diff. 

The change is getting more and more complicated. First of all the depending bug 180920 does not seem to be fixed. Second, the retrofitting of TopComponent to implement UndoRedo.Provider is not source compatible change, I need to add dependency on openide.awt for some modules to compile. Last, the retrofitting of CloneableEditorSupport to implement UndoRedo.Provider requires the getUndoRedo field to be made public.

Víťa promised to look at the NPE 180920 bug which can be simulated after applying the latest patch from this issue.

Is  Bug 175809 -  undo/redo disabled, but editor has focus
related to this issue?

The change is source incompatible and requires changes to many modules. Unless really necessary, I'd like to defer it after 6.9 is branched.

[JG01] Is it intentional in your patch that RedoAction.instance has undo=true while UndoAction.instance has redo=true? Might anyway be simpler to have just one attr, undo=true or undo=false, with

public static Action create(Map<?,?> map) {
  return new UndoRedoAction(Utilities.actionsGlobalContext(), (Boolean) map.get("undo"), true);
}


[JG02] {@link UndoRedo#Provider} will not work as far as I know; you need {@link org.openide.awt.UndoRedo.Provider}.

I've just created a hudson builder:
http://deadlock.netbeans.org/hudson/job/prototypes-context-aware-undo-redo-180614/
to verify that the changes are sane and remain buildable.

I am looking at the NbEditorKit code and there is:

    public static class NbUndoAction extends ActionFactory.UndoAction {

        public @Override void actionPerformed(ActionEvent evt, JTextComponent target) {
            Document doc = target.getDocument();
            if (doc.getProperty(BaseDocument.UNDO_MANAGER_PROP) != null) { // Basic way of undo
                super.actionPerformed(evt, target);
            } else { // Deleagte to system undo action
                // Delegate to system undo action
                UndoAction ua = (UndoAction)SystemAction.get(UndoAction.class);
                if (ua != null && ua.isEnabled()) {
                    ua.actionPerformed(evt);
                }
            }
        }

    }

as far as I can tell, if the document provides UndoRedo.Manager as BaseDocument.UNDO_MANAGER_PROP, then we don't need to change anything. Mílo, Ondro?

I think context sensitive Undo/Redo action is useful with or without its usages in editor. Unless there are objections I will tomorrow apply:
http://hg.netbeans.org/core-main/rev/0e1285942bb5

core-main#00798124636d

Yes, since UndoRedo.Manager extends javax.swing.undo.UndoManager it should work fine.

This is a wild guess, but could this change be the cause of bug 188363?

Is-there any reason why CloneableEditorSupport does not implement this (would require getUndoRedo field to be made public)? I have a multiview system with multiple components which default to the same CloneableEditorSupport for their UndoRedo; this provider would be very handy.

Also one of them is a second CloneableEditorSupport and if we could have the getUndoRedo field not final, life would be easier. Just a case scenario.

Originally I wanted to change CloneableEditorSupport as well, but its getUndoRedo() method is protected. If I wanted to implement the interface, I'd have had to make the method public. That would not be source compatible change - many existing codebases would not compile. I decided to avoid that.

Btw. if you are interested in MultiView watch bug 196810.