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.

Bug 184094 - REDO queue cleared on save
Summary: REDO queue cleared on save
Status: RESOLVED DUPLICATE of bug 21237
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 normal (vote)
Assignee: issues@editor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-14 04:34 UTC by chris4beta
Modified: 2010-04-14 08:42 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chris4beta 2010-04-14 04:34:44 UTC
I'll do my best to explain...

Say I make three changes to my file, and those change states are represented by the three dashes below:

| - - - |

If I click UNDO once, I move back one spot in the queue:

| - - - |
     ^
And clicking REDO would take me back to the end of the queue:

| - - - |
       ^

Now, if I UNDO twice and save the file. What currently happens is that all REDO states are cleared, and my queue would look like this:

| - |   instead of   | - - - |
   ^                    ^

I can no longer cycle forward through change states. Why does this matter? One situation where this causes me grief is when working with CSS files locally. I may add a few attributes, save, see how it looks, UNDO a few things, save, see how it looks, decide it looked better before and just want to hit REDO to get those changes back... Boom! No can do.

Another editor I use, PSPad, keeps your position in the UNDO/REDO queue after saving, so I can go back and forth with as many saves as I wish. It is only when I type something new into the editor that those future states are cleared. I think this is a better way of traveling through the history queue - keep it intact after saves, until we type something new.

Thanks for all the hard work!
Comment 1 Vitezslav Stejskal 2010-04-14 08:42:54 UTC

*** This bug has been marked as a duplicate of bug 21237 ***