undo appears to be broken

[bobjack]

Undo appears to be broken. Any significant sequence of undo's results
in corruption. I used to use undo/redo as a sort of cheap version
control, now I hardly dare use it at all.

I am using Python 2.5 on Vista/XP and the latest trunk.

Bob

[Edward K. Ream]

On Mon, Jun 23, 2008 at 4:33 AM, bobjack <bob...@post.com> wrote:

Undo appears to be broken.  Any significant sequence of undo's results
in corruption.  I used to use undo/redo as a sort of cheap version
control, now I hardly dare use it at all.

Can you be a bit more specific?

Edward

[bobjack]

If you try to undo past a changed headline then a headline unrelated
to the headline changed is corrupted. This is sometimes not
immediately obvious as the corrupted headline can be a long way from
where the changed headline was or where you were working when you
started the undo sequence.

Has no one else noticed this?

This is related to a previous bug report which you indicated could not
be fixed and had to be lived with. However in this context the bug is
very hard to live with. Having infinite undo isn't much use if you
can only use it if you don't change headlines :-(

Bob

On Jun 23, 2:37 pm, "Edward K. Ream" <edream...@gmail.com> wrote:

[bobjack]

Its difficult to nail down the exact circumstances and results.

The following does not show all the problems I have been experiencing
but it does serve to show that undo/redo is broken.

In a new window do Ctrl-I 1, Ctrl-I 2, Ctrl-I 3, to insert three
headlines named 1,2 and 3. Go back to 1 and insert 1 in the body, same
with 2 and 3.

Now use undo repeatedly to go back as far as you can, then use redo to
go as far forward as you can.

Observe the results.

Now do the same but revert leo to a pre-big-change version first.

In the old leo you will end up with three nodes 1,2,3 with 1,2,3 in
there respective bodies, just as one should expect, but in the new leo
you won't.

I'll try to find repeatable ways of demonstrating some of the other
problems.

Bob

[Edward K. Ream]

On Tue, Jun 24, 2008 at 6:16 AM, bobjack <bob...@post.com> wrote:

Its difficult to nail down the exact circumstances and results.

The following does not show all the problems I have been experiencing
but it does serve to show that undo/redo is broken.

Thanks for tracking this down.  I'll fix this before b1.

Edward

[TL]

> Has no one else noticed this?

The Vim documentation has the following entry under "Open issues" in
the "Vi documentation" node:

Undo command:
Using the "undo" command (key 'u') to undo a change to a node's
headline works better if, first, another node is selected and then the
edited node is reselected (key sequence "Ctrl-k, Ctrl-j").

I used to just use Ctrl-k to move to another node before using "undo"
but noticed that the current node was being changed instead of the
node I just left. It appeared to be trying to undo the last change
but to the wrong node.

I hope this helps.
TL

[Edward K. Ream]

On Tue, Jun 24, 2008 at 8:47 AM, Edward K. Ream <edre...@gmail.com> wrote:

The following does not show all the problems I have been experiencing
but it does serve to show that undo/redo is broken.

It appears there is a blunder in u.undoInsertNode.  I "cleverly" tried to use c.deleteOutline, but that cuts back the undo stack and probably does some other no-no's.

Imo, this is pretty good news: it means that the fix is local and really does not have anything to do with the various reorgs, at least not directly.  I'll be looking for similar blunders after I fix u.undoInsertNode.

Edward

[Edward K. Ream]

On Jun 24, 10:48 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> It appears there is a blunder in u.undoInsertNode.

The problem was much more interesting than that, and happily much
easier to fix. The fix is on the trunk at rev 579.

It turns out that a call to c.redraw_now must be made at the end of
undo() and redo() **before** setting u.undoing to False. If the
redraw is made later (as would happen in c.outerUpdate), a call to
c.endEditing will, via a complex chain of events, cause Leo to think
that a headline has been changed. Chaos will ensue, as the undo stack
gets "chopped" and other bad things happen.

It's possible that c.outerUpdate can be called instead of
c.redraw_now, but that's just a case of "greed" (trying to eliminate
unnecessary redraws during undo/redo). I won't mess with this until
after b1.

Anyway, the fix appears to work as expected, and furthermore, the bug
explains all the headline symptoms, so it looks like this simple fix
will likely fix all undo problems. We shall see...

Edward

[TL]

Running the latest trunk with no user key bindings (myLeoSettings.leo
file not used) shows the following behavior:

If, while editing a node (node in "Insert" state), an undo operation
is attempted, the undo will ignore any changes since the Insert state
was entered and, instead, undo the last change that occurred before
the Insert state was entered.

TL

[TL]

Running the latest trunk with the Vim key bindings shows the following
behavior:

Note: all steps below should leave current node in the Command state
(light blue background)

1. Select a node
2. Delete a character ('x' key)
! Undo menu item dimmed
3. Go to next node ('Ctrl-J' key)
! Undo menu item active
4. Delete a character ('x' key)
5. undo delete ('u' key)
! Restores previous node's character

In summary, it appears that any changes to a node's headline are not
placed in the edit history used by the undo command until after
another node has been selected.

TL

[Edward K. Ream]

On Thu, Jun 26, 2008 at 10:06 AM, TL <t...@tltools.net> wrote:

In summary, it appears that any changes to a node's headline are not
placed in the edit history used by the undo command until after
another node has been selected.

Thanks for this report.  I'll put it on the list for b2.

Edward