Undo/Redo behaviour not consistent

[stefan-kolb]

Undo/Redo behaviour not consistent between pressing CTRL-Z, edit->undo, undo icon.
Sometimes it removes the last two edits, etc. pp.

[matthiasgeiger]

Current behavior is:

• Using Ctrl-Z: All changes can be reverted step-by-step (during editing a field)
• Using Icon: All changes are reverted since starting the edit of a field
• Using Edit -> Undo: All changes are reverted since starting the edit of a field. BUT: If it is the first edit and the cursor is still in the field (i.e., editing is not completed), Edit -> Undo throws a javax.swing.undo.CannotUndoException (This does NOT happen if the icon is used!)

[matthiasgeiger]

Some intermediate results after debugging the code: The reason for the different behavior between Icon and Menu is in net.sf.jabref.gui.entryeditor.EntryEditorTabFocusListener method focusLost line 117-120:

        if (!event.isTemporary()) {
            entryEditorTab.getParent().updateField(event.getSource());
        }

If the focus is not lost temporary the data of the field will be stored.
Clicking on the icon is a permanent loss of focus - selecting a menu item is not.

Of course, it is possible to remove the if-condition and store changes in the case of temporary focus loss, but I'm not sure which side effects might be caused by this change.
Changing it locally revealed no obvious problems - all other events (right-click, switching to another program, changing textfield) seem to be "permanent" event in which the changes are already saved (and therefore undoable).

But as I am not able to guarantee the correctness of this fix, it is your decision whether this should be applied 😯

[matthiasgeiger]

Regarding "Ctrl-Z" in the textfields: Here for each textfield a default Swing UndoManager is used and not the globally used jabref CountingUndoManager which is called by the icon/menu.
This enables undoing yet unsaved changes (see previous comment) - side effect: After changing field A and switching focus to unchanged field B it is not possible to "undo" changes in A using ctrl-z.

If no textfield is selected (e.g., after switching back from edit to preview mode) ctrl-z is calling the CountingUndoManager.

[koppor]

I remeber was that the reason somehow was to offer micro undoes at the text fields. Possibly, we have to use the undomanager there too and to collect a number of changes to a single change and use the CountingUndoManager. Firefox, Word, etc have an algrithm for that, but I don't know the details. While typing, "CTRL-Z" stops removing in the middle of a word.

[matthiasgeiger]

In order to use the CountingUndoManager changes have to be stored before the can be undone (see the issue with Edit->Undo #129 (comment)). Storing is triggered when the focus of the field is lost - so simply using the CountingUndoManager will not work as during editing the field the focus is still on the textfield.

But thinking about the current solution it is not so bad (apart from the Menu-Bug): While editing it is possible to "micro undo" each keystroke/paste action using Ctrl-Z. After finishing the edit the whole edit is reverted using Ctrl-Z.
People who do not use the shortcut are only able to undo whole edits.

[koppor]

I think, I went through the same thinkings:
A) Consistency with other programs (CTRL+z and menu action always the same behavior)
B) "intuitive" use of CTRL+z

👍 for keeping as-is: A rewrite that the global action behaves like the CTRL+z action causes too much effort.

[stefan-kolb]

@JabRef/developers Will we ever work on this or should we close it as a reference.

[lenhard]

We probably should, but we probably won't :-)

There is simply too much work to be done and so far no real user has complained about this.

[tobiasdiez]

Can we tag it as unimportant? Maybe after moving to JavaFX this issue is easier to resolve.