From time to time undo-tree behaves strangely. With a single undo step it can undo a char insert or whole paragraphs that took several minutes to enter. Worse, sometimes it fails while trying to redo with:
primitive-undo: Unrecognized entry in undo list undo-tree-canary Combined with one of those huge undo steps, this amounts to serious data loss. Does someone else experience these problems? Is Evil handicapped in some way if I stop using undo-tree?
It's a known issue with undo tree unrelated to evil. On Nov 10, 2014 7:41 AM, "Óscar Fuentes" <[email protected]> wrote:
From time to time undo-tree behaves strangely. With a single undo step it can undo a char insert or whole paragraphs that took several minutes to enter. Worse, sometimes it fails while trying to redo with:
primitive-undo: Unrecognized entry in undo list undo-tree-canary
Combined with one of those huge undo steps, this amounts to serious data loss.
Does someone else experience these problems?
Is Evil handicapped in some way if I stop using undo-tree?
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
I think there are two issues: - the variable size of undo steps - the error when redoing. The first issue arises from the fact that Evil considers anything that happens from entering insert mode until leaving it as one edit. So if you enter insert mode, type one character, and leave insert mode, undo deletes a single character. However, if you enter a whole paragraph in insert mode, undo will remove that paragraph. This is not consistent with Vim's behavior. In Vim, a new edit unit is started whenever you move the cursor in insert mode (by means other than entering text). Depending on how you work, this may still give you a too coarse-grained granularity but it's better than what Evil does. Evil has a customization variable that allows you to change the granularity of edits in the undo history: (setq evil-want-fine-undo t) With this setting, you also get new edit units when moving the cursor in insert mode. However, it also messes with how things like the `cw` operation are handled. In Vim, replacing a word by another and then undoing reverts to the original word in one step. In Evil with the above setting, you have to undo twice: once for inserting the new word and once for deleting the old word. This is rarely what you want and in my opinion breaks the semantics of the replace operation (which should be atomic). The second issue is the error that you're observing when redoing. I never encountered this problem. Titus On 2014-11-10 Mon 09:01, Barry OReilly wrote:
It's a known issue with undo tree unrelated to evil. On Nov 10, 2014 7:41 AM, "Óscar Fuentes" <[email protected]> wrote:
From time to time undo-tree behaves strangely. With a single undo step it can undo a char insert or whole paragraphs that took several minutes to enter. Worse, sometimes it fails while trying to redo with:
primitive-undo: Unrecognized entry in undo list undo-tree-canary
Combined with one of those huge undo steps, this amounts to serious data loss.
Does someone else experience these problems?
Is Evil handicapped in some way if I stop using undo-tree?
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
Titus von der Malsburg <[email protected]> writes:
I think there are two issues:
- the variable size of undo steps - the error when redoing.
Yes, but one makes the other more serious.
The first issue arises from the fact that Evil considers anything that happens from entering insert mode until leaving it as one edit.
That was I thought until I observed, multiple times, how undo worked one char at a time after writing some text. No mode change, no cursor movement, just writing text and then undoing. I'm not so sure about this, but I also observed how undo removes multiple chunks of text that were written with mode changes and cursor movements in between. [snip]
The second issue is the error that you're observing when redoing. I never encountered this problem.
This happens every other month, but it hurts. There are other problems on undo-tree, although not of the data-loss type. It looks quite unreliable to me. IIRC the author explained on emacs-devel that some characteristics of Emacs' undo implementation made things difficult for him. I still don't know if not using undo-tree has consequences on Evil's behavior, apart from going back to traditional Emacs undo features, but let's assume that there is no problem, so I'll ditch undo-tree.
On 2014-11-10 Mon 10:45, Óscar Fuentes wrote:
That was I thought until I observed, multiple times, how undo worked one char at a time after writing some text. No mode change, no cursor movement, just writing text and then undoing.
Ah, I see. I can't remember that this ever happened to me and I'm using Evil since the earliest usable versions. My experience is that undo-tree works flawlessly. Is it possible that something in your Emacs configuration interferes with undo-tree and/or Evil? To me it sounds like that.
I'm not so sure about this, but I also observed how undo removes multiple chunks of text that were written with mode changes and cursor movements in between.
That, too, never happened to me. Perhaps you can try to find reproducible examples for these problems. Next, you could start emacs -Q, load Evil and see whether the problem persists. If not, it's a configuration issue. Titus
You can use builtin undo system with Evil. FWIW, I've only seen that undo-tree bug when using undo in region. On Mon, Nov 10, 2014 at 10:45 AM, Óscar Fuentes <[email protected]> wrote:
Titus von der Malsburg <[email protected]> writes:
I think there are two issues:
- the variable size of undo steps - the error when redoing.
Yes, but one makes the other more serious.
The first issue arises from the fact that Evil considers anything that happens from entering insert mode until leaving it as one edit.
That was I thought until I observed, multiple times, how undo worked one char at a time after writing some text. No mode change, no cursor movement, just writing text and then undoing.
I'm not so sure about this, but I also observed how undo removes multiple chunks of text that were written with mode changes and cursor movements in between.
[snip]
The second issue is the error that you're observing when redoing. I never encountered this problem.
This happens every other month, but it hurts.
There are other problems on undo-tree, although not of the data-loss type. It looks quite unreliable to me. IIRC the author explained on emacs-devel that some characteristics of Emacs' undo implementation made things difficult for him.
I still don't know if not using undo-tree has consequences on Evil's behavior, apart from going back to traditional Emacs undo features, but let's assume that there is no problem, so I'll ditch undo-tree.
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
participants (3)
-
Barry OReilly -
Titus von der Malsburg -
Óscar Fuentes