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.
Undo is possible after doing a save, but redo not.
Set target milestone to TBD
This request needs to be implemented in the CloneableEditorSupport in openide/editor. The current algorithm adds extra undoable edits at time when file save is peformed. Undoing that edit makes the file modified while redo makes it unmodified. It works fine but the problematic case is save after redo because it adds that extra UE into the middle of the undo queue which throws away the rest of the queue (the undone edits). The current algorithm needs to be changed. IMHO the only way is to wrap each UE coming from the document with an extra UE class and have there an extra boolean savePerformedAfterThisEdit; whether save was performed after that edit was done. If this boolean would be set to true then the undo of the wrapped item would call markModified() and the redo would do markUnmodified(). The CES would hold a pointer to the wrapper UE WrapperUndoableEdit lastSaveEdit; corresponding to the last save operation. Before changing the value of lastSaveEdit (because of a new save operation) it would first clear the lastSaveEdit.savePerformedAfterThisEdit flag. Reassigning to openide/editor for further evaluation.
Reassigning to new module owner mslama.
*** Bug 177504 has been marked as a duplicate of this bug. ***
Duplicates 120981 168303 138591
*** Bug 138591 has been marked as a duplicate of this bug. ***
*** Bug 184094 has been marked as a duplicate of this bug. ***
*** Bug 120981 has been marked as a duplicate of this bug. ***
*** Bug 186983 has been marked as a duplicate of this bug. ***
I can't imagine since 3.3 this feature haven't implement.. this is basic text editor function, I hope Netbeans developer should take serious on this. I tried 6.10 M1 this feature still haven't fix it... please do something.
shiroamada please don't change bug priorities unless they are assigned to yourself.
I understand your frustration. I used to think that once we've implemented automatic-trailing-whitespace-removal then we would only be able to implement Redo-after-save in case the ATWR would be off (since ATWR generates edits that overwrite rest of UndoManager's queue) which of course gave RAS much less importance. But recently I've got an idea that we could possibly implement RAS with ATWR on. I need some more thinking about a concrete implementation but it should be feasible.
It's hard to believe that this bug has been open for eight years. I have also suffered work loss from this issue, it's simply not intuitive or expected behaviour. I hope this gets re-prioritized and taken seriously.
Excuse me, but why this bug has no P1 or P2 priority? It's basic feature, most editors have...
Created attachment 103342 [details] failing test cases One test fails because canRedo() is false after save. The other tests investigate state of undoManager after "undo after save". I believe those can be considered as part of this issue report.
Should have mentioned that these tests came from work on Bug 103467 and Bug 192491
I really would like this implemented as well. I came from using a pretty simple programming text editor - Crimson Editor - and had a fun surprise after I tried doing this for the first time in NetBeans and it didn't work. Here's what happened in my case if you need a real world example - you edit a file, then realize you'd rather save the changes in a new file but you already saved. So you undo back to the original point and save. Then you redo back to current and save as a new file. It's really handy and can be a time saver when you can use the undo/redo in that way. About Crimson Editor - although it's a basic editor with tiny footprint, it really works well and does several things better in the UI that NetBeans could adapt, particularly with Find/Replace functionality and general editing like indenting existing lines and placing of curly brackets. I'd like to say more about that but this is a bug report.
any idea when will this fixed? more than 9 years bug..
I am adding my vote hoping this will be fixed. I am using Netbeans 7 and is still a problem. It is very dangerous and although I love Netbeans it is frustrating that I cannot undo something and save it unless I copy and paste that into another text editor first..
>20 dups + votes -> P1 based on http://wiki.netbeans.org/BugPriorityGuidelines
P2 still targeted for 7.1 final (not for beta).
I have a working solution (diff attached) but I still have 30 tests failing in openide.text (160 tests pass). I have resolved several failures but it's very slow for me since sometimes I do not fully understand why a particular test asserts certain rather specific things. I'll talk to Yarda regarding the tests.
Created attachment 113004 [details] Redo after Save diff (30 failing tests)
Hey that makes me happy! I'll be watching to update the moment it's out.
It should now be complete. There's a new UndoRedoManager implementation that supports redo after save and allows for save actions (such as trailing whitespace removal). The 196 openide.text tests pass. I have fixed NbEditorLikeKit.Doc implementation to notify VetoableChangeListener before acquiring writeLock(). I have inherited tests from openide.text into editor module to verify BaseDocument operation with the openide.text (there were some inherited openide.text tests this way already). Although I tried to keep Ernie's grouping undo manager separate during making the undo grouping tests to pass it was becoming more and more complex so in the end I have merged the grouping undo manager into UndoRedoManager. http://hg.netbeans.org/jet-main/rev/11f80032f91d
That is exciting news! Personally, I appreciate the effort on this bug, it is my one major complaint with Netbeans. I look forward to seeing it released. It's a shame though... another four months and this bug would have been open for a decade. :D
Although this bug has been open for almost a decade, IIRC for a stretch of a year or three redo did work properly . Then it reverted back at some point.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/11f80032f91d User: Miloslav Metelka <mmetelka@netbeans.org> Log: #21237 - Redo should be possible after save.
I have tried it and I faced a exception [1]. Probably related... [1] http://statistics.netbeans.org/analytics/detail.do?id=182826
(In reply to comment #31) > I have tried it and I faced a exception [1]. Probably related... > > [1] http://statistics.netbeans.org/analytics/detail.do?id=182826 Did you build Netbeans yourself? The fix was just integrated today, so AFAIK it won't be available until tomorrow's build.
Yes, I built it myself earlier today from main repo. I will update this later and retest it, maybe it is already fixed. Product Version: NetBeans IDE Dev (Build 20111111-898b85081926) Java: 1.7.0_01; Java HotSpot(TM) Client VM 21.1-b02 System: Linux version 2.6.32-35-generic-pae running on i386; ISO-8859-1; en_US (nb)
I'm sorry, but I have to reopen this. Changes in CloneableEditorSupport.getUndoRedo method caused http://netbeans.org/bugzilla/show_bug.cgi?id=204963 This method returns only instances of new UndoRedoManager, other classes which extend from UndoRedo.Manager are ignored. For *.properties files there is UndoRedo manager to handle edits of multiple files (Context menu/Open). I'm afraid similar problems could have any other component with its own UndoRedo manager.
Issue #204963 is fixed.
verified
Created attachment 113663 [details] Additional tests All the old tests I had passed and are now in this patch. The patch introduces a new file, UndoRedoAfterSaveTest.java, which is a cleaned up version of the "failing test cases" attachment which I've obsoleted. The patch also un-comments some checks in UndoRedoWrappingCooperationTest.java which is the original tests for grouping.