Undo

RefactorErl had an undo operation for refactorings, but with this method could you lose some modifications. Namely if the you edit the text after a refactoring, then undo the changes, all changes since the last refactoring were lost. This undo was one step only, but it could be extended to more steps. However, if we extend this undo, at refactoring undo there can arise conflicts among changes of editing and the transformations - and also among two transformations -, but refactoring undo should handle these conflicts, and it must be as complete as possible. In this section we introduce a new undo/redo mechanism for the tool integrated in Emacs and Vim.

Installation

The new undo mechanism is disabled by default, to enable it, we need additional software components. This extended undo is implemented by a stand alone Haskell program, so we need ghci Haskell Compiler and cabal packaging system, that makes easier the installation of the required packages, modules.

• The Haskell compiler can be downloaded from the website ​http://www.haskell.org/ghc/download.
• Cabal is available at ​http://www.haskell.org/cabal/download.html or on Linux systems with cabal-install package.
• For compiling the sources of this component, you have to run the "make bufsrv" in the root directory of the tool, or run the "referl" with "-build tool -bufsrv" option.
• To enable the new undo mode you had to set the undo mode in the editor to selective undo.

The other undo mode is enabled by default, or you can choose it with one step mode. In this mode the undo operation restores the files to their state before the last refactoring step. This restoration includes dropping all the changes that you may have done to these files. You have been warned.

Usage

The undo (redo) function is available in the Refactor menu with Undo (Redo) menu item. Calling the last change point in the Undo menu, the program undoes the last change in the current file. Case refactoring the modifications will be rejected in every affected file, but in some cases can conflits arise. When you edit an affected file, or make one another refactoring, the system checks, if the second change affects the refactored area in the file. If the changes are overlapped, the undo reverts also this change, otherwise only the first one, and you get a merged state of the file. At more complex changes can also more changes get reversed. In both cases the changes can be redone until a newer modification.

You can undo also older changes, not only the last one. This operation is called selective undo. In the undo menu under last change option there are the last 5 changes listed. You can choose from them, and the tool checks, if the chosen change conflicts with newer changes after that, similarly to the simple case at refactoring conflicts.

Examples of behaviour

We give two examples, for showing the behaviour of the merging algorithm of the conflicts.

Example 1.

1. we move the pzip function from module from to module xlists
2. we edit the module xlists after refactoring in area, that is not affected by refactoring (flatsort)
3. then we undo the refactoring in the module from: merge is successful, the edited text is unchanged

Example 2.

1. we move the pzip function from module from to module xlists
2. item we edit the module xlists after refactoring in area, that is affected by refactoring (pzip)
3. then we undo the refactoring in the module from: conflict arises, the change by editing is rejected