Fix undo/redo cursor positions

[pythonesque]

It seems like the "after" cursor isn't being set correctly currently, so when you redo the cursor ends up in the wrong place (i.e. not the place it was before the edit began). Seems like this should be an easy fix.

[pythonesque]

Also, it looks like the "fix undo/redo across pages" fix was reverted (or at least, it no longer appears to be working, as the screen doesn't scroll properly).

[withoutboats]

"when you redo the cursor ends up in the wrong place (i.e. not the place it was before the edit began)."

Is this actually the wrong place? It ends up where the redo occurred, which is the same behavior that I get in gedit and vim (my vimrc is unmodified from whatever is installed on Ubuntu 14.04). It is trivial to change (just reset the end_point when the buffer's undo and redo methods are handling the transaction), but I'm not sure what we want.

The other change is also trivial, I'll push a fix. EDIT: Of course, not actually trivial. But I'll roll that fix into fixing horizontal scrolling.

[pythonesque]

Hm, you seem to be right about vim's default behavior. It intuitively feels wrong to me (shouldn't redoing put your cursor where it was after the edit, not before it?) but maybe I am the one who's wrong here.

[withoutboats]

It does put the cursor where it was after the edit, just not after the additional actions of shifting the cursor's position. When we create transactions that include larger blocks than single insertions and removals, we can incorporate cursor movements into the transaction (probably optionally).

[pythonesque]

Cursor movements were already incorporated into the transaction before, so this is a behavior change for sure. But I can definitely understand the perspective that they aren't part of the edit.

[gchp]

Still seeing some weird behaviour with this.

• open a file
• enter the characters "test"
• press Ctrl-z to undo
• press Ctrl-y to redo

The cursor should be positioned like so: tes|t
Instead, it is positioned like this: te|st.

Seems off by one every time.

[gchp]

Perhaps the wrong value is being stored in transaction.end_point?