Undo/Redo: Redo not adding back to Undo stack

Help & Support
1

Hi,

Perhaps a suggestion as I'm not sure if the current behavior is intended or not.

With sequential undo on:

When Dopus works how I expect:
When cutting a file, and undoing the action, then redoing the action, after the action has been redone, one still has the option to UNDO it again. For instance, you can repeatedly "UNDO" followed by "REDO" and this will switch between two different states. This is the behavior I expect and want, and how most other apps I've used behave. [And Dopus does work like this for CUTS]

When Dopus doesn't work how I expect:
In Dopus, for COPY or certain other operations [specifically Delete], when redoing, the original undo action associated with the redo is not added back to the undo stack, and so that results in unusual behaviour.

For instance,

Copy a file "1.txt" from folder A to folder B.
Copy another file, "2.txt" from folder A to folder B.

Undo the last operation, and "2.txt" will be reverted back to only being on "A".
Redo that operation, and "2.txt" will appear in "B" again.
Try to Undo it once more however results in "1.txt" being deleted from "B", where I would have expected "2.txt" to have been deleted again.

Expected/Desired behavior:
In most apps I like to think of Undo/Redo like a "timeline" of actions, UNDO goes backward in time, REDO goes forward in time. When a fresh action other than UNDO is performed, the REDO list is cleared, i.e. the list of the "future" is cleared whenever a fresh future is begun. In this case, the UNDO list is a record of the past and so when a REDO action occurs, one is essentially moving forward in time and an UNDO should allow one to go back in time again.

TLDR: My suggestion is use the same behaviour as is currently happening for CUT for other actions. I.e. when a REDO occurs, that redo should also be added back to the undo list.

Update:
I found it is working as expected for rename operations also. It is not working for copy or delete operations.

2

That's not what I see here, fwiw. The second undo moves 2.txt back to A, and then the third undo moves 1.txt back.

3

Is this with a COPY, operation, not a cut? Sorry I initially wrote my post sounding like I was talking about cuts, but cuts actually work for me. (I'm on version 13.22)

4

Ok yes with a straight copy I see what you're describing. Will investigate...

5

It's because currently a restore from the recycle bin does not go into the undo log as an action that can itself be undone (I guess no one ever asked to be able to undo an undelete before!)

We'll change this in the first beta after 13.23 is released.

6

Awesome, thank you!

Fyi I checked a REDO of a delete in 13.22 and that also is not working. (Presumably for the same reason)
Steps to reproduce:

  1. Delete a file
  2. Undo the delete
  3. Attempt REDO (but redo list is empty)

--

Haha, yeah I suppose I'm prob especially inclined to using UNDO/REDO, I sometimes use it to compare two different states visually when deciding how to plan or structure something, and find traveling forward and backward with undo/redo can often be the simplest way to do that.