When saving the buffer, change list got emptied.

[TheBB]

Originally reported by: ReneFroger (Bitbucket: ReneFroger, GitHub: ReneFroger)

---

I use Emacs 24.4 in GUI-mode

From the Vim / Evil documentation:

     g;          Go to [count] older position in change list.

     g,          Go to [count] newer cursor position in change list.

When I save the buffer inside Vim, and then press g;, it will go to the latest changed postion.

In Evil, after saving a buffer, I press g;, which calls the function (goto-last-change ARG). But I got the error message that there is no further change info.

---

• Bitbucket: https://bitbucket.org/lyro/evil/issue/522

[TheBB]

Original comment by Frank Fischer (Bitbucket: lyro, GitHub: lyro):

---

Is this also true when starting with make emacs in Evil's source directory?

[TheBB]

Original comment by ReneFroger (Bitbucket: ReneFroger, GitHub: ReneFroger):

---

I use Emacs 24.4 in Windows 7 x64, that I didn't have compiled. I use the compiled Emacs 24.4 by Harroogan from this link.

[TheBB]

Original comment by Frank Fischer (Bitbucket: lyro, GitHub: lyro):

---

No, your Emacs version is fine. I wanted you to execute make emacs in Evil's source directory. If this is not possible, please check with a fresh, unconfigured Emacs, i.e. execute something like

emacs -Q -L /path/to/evil -l evil --eval '(evil-mode 1)'

(the make emacs command does nothing else). Alternatively, please remove everything from your .emacs file except Evil and test if the problem remains.

(I'm asking because I cannot reproduce the problem, everything works well for me.)

[TheBB]

Original comment by ReneFroger (Bitbucket: ReneFroger, GitHub: ReneFroger):

---

I couldn't got it working from the command line. But with command emacs only, it started.

But I disabled my custom config, and you're right.. without a config, after saving the buffers, Evil still goes back to the latest change. So it's propably related to my configuration.

Thanks for your support, will look further into my setup!

[TheBB]

Original comment by ReneFroger (Bitbucket: ReneFroger, GitHub: ReneFroger):

---

I believe I found the culprit here:

(setq undo-tree-auto-save-history t)

The package Undo Tree was inspired by Vim, with a logical way of undo history. Seems this is incompatible with Evil.

But I don't understand one thing.

The Vim-like undo tree is already active when I make some changes and go back with g;.
The Vim undo tree is still active when saving, but after saving, then this bug will only appear. And I can't figure out why.

Any idea?

[TheBB]

Original comment by ReneFroger (Bitbucket: ReneFroger, GitHub: ReneFroger):

---

Related to this.

[TheBB]

Original comment by Ivan Brennan (Bitbucket: ivanbrennan, GitHub: ivanbrennan):

---

This is unfortunate, as it's nice to be able to persist your undo history. With undo-tree-auto-save-history set to a non-nil value, saving will trigger undo-tree-save-history. I was able to repro this bug without auto-save by calling undo-tree-save-history directly.

Visit a new buffer

C-x C-f mybuffer RET

Insert text, insert newtext below, return to first line

i text ESC
o newtext ESC
k

Save the undo history

M-x undo-tree-save-history RET

Try to go to last change

g;

goto-last-change reports "No further change info"

If you inspect buffer-undo-list before and after calling undo-tree-save-history, you'll see it gets cleared out.

• before: (nil (1 . 8) (1 . 2) (1 . 5) (t . -1))
• after: (nil undo-tree-canary)

I noticed undo-tree-save-history calls undo-list-transfer-to-tree, and that appears to be clearing the undo-list in the process of saving undo info to the tree. I tried the same experiment above and called undo-list-transfer-to-tree instead of undo-tree-save-history and saw the same effect.

One thing I still don't understand is why this bug doesn't occur on every call to undo-tree-undo, as that function ends up triggering undo-list-transfer-to-tree as well.

[ReneFroger]

Is this bug still open? It was surprisingly to see my comments back here from somewhere, thanks for that!

[wasamasa]

Why, yes, it is.

[TheBB]

Undo-tree is no longer default after #1360, so closing.