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.
This is a REGRESSION for jVi users. (found when investigating Bug 199699) Prior to 7.0, the jVi patch for NB with UndoGroupManager was implemented with class Manager extends UndoGroupManager implements UndoRedo in org/openide/awt/UndoRedo.java. So in PropertiesEditorSupport class UndoRedoStampFlagManager extends UndoRedo.Manager inherited the edit grouping capabilities. In 7.0, UndoGroupManager was moved into CES and since PropertiesEditorSupport does @Override protected UndoRedo.Manager createUndoRedoManager () and the grouping capability is lost. It is interesting to note Míla's request to make createUndoRedoManager final in Bug 103467 comment 48. It looks like the property editor provides its own undo manager so it can do grouping. It that's true, the code can be simplified by using the grouping capability provided in CES. The original patch for 7.0 put the UndoGroupManager into UndoRedo.Manager but it was moved to CES to satisfy Y12 in Bug 103467 comment 36. I should have continued arguing following > Y12 - "generic enough or is tight directly to CloneableEditorSupport?" ... A generic undo manager which provides chunking needs a way for a manager, like CES, to specify that a particular edit can not be coalesced.... in Bug 103467 comment 37 to keep the UndoGroupManager as part of UndoRedo.Manager Two possible solutions for this bug 1) Move UndoGroupManager into UndoRedo.Manager 2) Have PropertiesEditorSupport use CES's undo manager Note that both these things could be done. 1) Can be done easily. We can continue the discussion from Y12 about why it belongs there. The move can be made and the only additional API is exposing interface UndoRedo.Manger.SeparateEdit (or something like that) 2) could be done when/if someone wants to.
> looks like the property editor [has] own undo manager [for] grouping No, it's more than just that. After a quick look, it seems its primarily about coordinating undo/redo between a table editor and a document editor. AFAICT, moving UndoGroupManager into UndoRedo.Manager and supporting document edit chunking won't interfere.
reassigned to proper component, I believe that this issue is about editing (and UndoRedo) of *.properties files.
With option 1) the .properties Undo/Redo still won't work 100% right (regardless whether before or after implementation of Redo-after-Save issue #21237). For example URM in CloneableEditorSupport calls notifyUnmodify() when undoing into savepoint so the following would fail for .properties: 1) Open .properties 2) Make modification 3) Save the file 4) Make another modification 5) Undo the modification 6) The file will stay modified although it should be marked as unmodified. So IMHO the only option is 2) with adding the extra undo/redo functionality that particular supports require into CES undo manager.
In this case I would need the CES UndoRedo manager to provide time stamp of UndoableEdits (see e.g. PropertiesEditorSupport.UndoRedoStampFlagManager.getTimeStampOfEditToBeUndone method). Is it possible Milo?
*** Bug 144073 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > In this case I would need the CES UndoRedo manager to provide ... Have you looked at the new API with Bug 204828 ?
The API should be usable for the time stamps in properties. Can the properties become involved in refactoring?
(In reply to comment #7) > The API should be usable for the time stamps in properties. Can the properties > become involved in refactoring? Sure, they can. Let me know what you would need...