-
Notifications
You must be signed in to change notification settings - Fork 281
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove undo-tree dependency #1074
Comments
Is there some specific set of changes needed for this? I tried with the below and got no errors (this doesn't load evil, but as far as I understand the bug is not related to evil-mode).
Where is (defconst bug-1074-dir
(file-name-directory (or load-file-name buffer-file-name)))
(setq undo-limit 78643200)
(setq undo-outer-limit 104857600)
(setq undo-strong-limit 157286400)
(setq undo-tree-mode-lighter " UN")
(setq undo-tree-auto-save-history t)
(setq undo-tree-enable-undo-in-region nil)
(setq undo-tree-history-directory-alist `(("." . ,(expand-file-name "undo" bug-1074-dir))))
(add-hook 'undo-tree-visualizer-mode-hook
(lambda ()
(undo-tree-visualizer-selection-mode)
(setq display-line-numbers nil)))
(add-to-list 'load-path (expand-file-name "../elpa/packages/undo-tree/" bug-1074-dir))
(require 'undo-tree)
(global-undo-tree-mode 1)
(defun bug-1074-do-changes ()
(interactive)
(let ((file (expand-file-name "xx.txt" bug-1074-dir)))
(with-current-buffer (find-file-noselect file)
(pop-to-buffer-same-window (current-buffer))
(dotimes (i 30)
(insert (format "%d\n" i))
(save-buffer)))))
(defun bug-1074-undo ()
(interactive)
(let ((file (expand-file-name "xx.txt" bug-1074-dir)))
(with-current-buffer (find-file-noselect file)
(pop-to-buffer-same-window (current-buffer))
(dotimes (i 30)
(undo-tree-undo)))))
(defun bug-1074-redo ()
(interactive)
(let ((file (expand-file-name "xx.txt" bug-1074-dir)))
(with-current-buffer (find-file-noselect file)
(pop-to-buffer-same-window (current-buffer))
(dotimes (i 30)
(undo-tree-redo))))) |
You're correct that the problem is with Unfortunately, there are two problems here. First, while it is reasonable to expect a set of steps to reproduce the error, a definitive way to reproduce it has yet to be found. Refer to the links @mrbig033 provided to see various other suggested steps. No one has found a way to reproduce it reliably. Second, the package author is unlikely to fix the problem any time soon. To quote the author from one of the linked bug reports,
He's apparently a busy man, too. The previous link suggests recompiling Evil without the Maybe there's a way to disable the loading of |
From what I read there, recompiling simply has the same effect as
Well, finding a way to reproduce the problem, that's really what we're missing. |
I've never not been able to reproduce this issue with my config and stopped using undo tree entirely a while ago. @lawlist may know how to reliably reproduce this problem. From my understanding, he has fixed this issue for various cases in his fork. |
See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16377#55 Quote from Dr. Cubitt:
|
That's been in my config and has never affected/prevented corruption (with persistent undo). Based on the linked spacemacs issues, other users have had the same experience. Are you saying that this is the cause of corruption (or is at least the cause with persistence disabled)? |
I am going to go out on a limb and assume corruption with persistent undo might mean that Emacs crashes or fails to load the undo-tree history file. If that is the case, there are two causes I have encountered: (1) on OSX, the undo tree is rather large and Emacs 26+ cannot handle it; or, (2) the undo-tree history file contains |
Chiming in with another report that |
For me, It happens even with persistent mode off. It's not causing problem though, since I don't trust it anymore and simply don't rely on it. |
I have a more basic problem with undo-tree; It bundles too many changes as a single change. E.g., I have typed, deleted, inserted a new line, then ran a command I didn't like, and so I undo, and go back to the beginning. |
@NightMachinary for that you can try experimenting with |
@NightMachinary -- see my answer on stackexchange: https://emacs.stackexchange.com/a/47349/2287 |
I am more experienced with Elisp now. It seems that
Altogether, that section of my (package-initialize)
(require 'package)
(add-to-list 'package-archives
'("melpa" . "http://melpa.org/packages/") t)
(package-refresh-contents)
;; Don't load undo-tree.
(setq load-path (remove "/home/lorem/.emacs.d/elpa/undo-tree-0.6.5" load-path)) Unfortunately, you can't just delete
I wonder whether one of the packages mentioned on the emacswiki, which don't rely on
could be used instead? |
What's your version of evil? This solution didn't work at least since January 2017. I tried your solution both with the older evil and the most recent one. Trying FTR emacs stackexchange question about this bug has a similar answer, with the same effect. |
I'm running evil 1.2.14. When I use By default, Emacs doesn't have a native "redo" function, per se. It only has
Admittedly, not loading You can learn more about how Emacs |
Because it is buggy and unnecessary. See <emacs-evil/evil#1074>. * gnu/packages/emacs-xyz.scm (emacs-evil)[propagated-inputs]: Remove emacs-undo-tree and emacs-goto-chg.
A new undo-tree release has been made (0.7), which looks like it goes some way toward mitigating errors people are seeing. Let me know if you experience problems with the new version. |
It seems, ELPA haven't updated yet the package, so here's a few links so people wouldn't search them: |
It's definitely on ELPA: https://elpa.gnu.org/packages/undo-tree.html |
Oh, indeed, this is odd. I'm still seeing latest version as 20170706.246 even when I |
That sounds like a MELPA version. Not sure how, as undo-tree doesn't seem to be present in MELPA. Maybe it used to be? |
@Hi-Angel In the |
Having learned the potential root causes from this blog post, I sparked a discussion about this new release regarding possible suggestions and further improvements <Lost or corrupted `undo-tree' history>. Feel free to join. |
I am now using undo-fu and it's working well for me. |
I've recently made some updates to undo-fu, namely, ensuring redo doesn't undo after existing undo/redo commands. I think this is suitable for evil-mode. |
undo-fu seems to lack saving history to file, so I don't think it is. |
There are existing packages that can save the undo history although I didn't try them out yet: see, https://stackoverflow.com/questions/2985050 Said differently, if this feature is important, it may be best to support via existing packages made for the purpose of restoring the session. Stability is a feature too, over the years there have been many reports of bugs, this should be taken into account when considering alternatives to undo-tree, exactly how it's done - I'm not so fussed - undo-tree could be optional or there could be a way to switch out undo back-ends. |
Undo-tree author+maintainer here. I turned Evil recently :) So might be able to help investigate this... The "unrecognized entry in undo list undo-tree-canary" error when using undo-tree and Evil may due to a small number of Undo-tree-mode puts the symbol If anyone has a recipe to reproduce the error, starting from Toby |
This seems to be a case where
Reproduction steps:With the
On startup the variable
Observed:The minibuffer shows:
When the steps above (from switch buffer...), are followed right after starting Emacs -q, without checking the
I don't know if it's helpful but if the
Then follow the steps above from (switch buffer...),
System Info
|
@duianto You are a genius at coming up with these steps-to-reproduce! As always, this was really helpful. At least for this example, the problem is indeed The problem here is buried within the The In any case, whatever the reason for it, at first sight this way of doing things might appear to be safe. As long as no However, @duianto's sequence up to the The second A kludgy fix for this particular issue would be for A slightly less kludgy fix might be to not short-circuit Emacs' undo system in However, both of these "fixes" paper over the underlying problem. I strongly suspect there will be other cases that neither change will fix. The real problem this is that every A proper fix may take more time and effort, as I don't understand every detail of what those |
undo-tree has lots of subtle issues: emacs-evil/evil#1074. Try and work around that by using the simpler undo-fu package. There's no tree visualization here, though.
What about redefining
(I took the opportunity to fix the docstring at the same time. The current docstring misleadingly implies Not sure yet if this fixes every |
I'm not sure what's expected either. The reproduction steps were just reduced to those, after reading your comment that The last line in the fix is outside the
Because pasting shows:
Moving it inside the
However now the
|
The last line is intentionally outside the
This fixes the error in your example for me. I wonder if the new code is being called in your testing? Because |
👍 The latest version doesn't show the void message. I replaced the Line 3523 in 6316dae
Removed all And restarted Emacs. The message remains:
It didn't help to recompile the evil directory: Note:Adding source: |
It doesn't seem to be related to my custom setup. And without the call to the local mode hook. It isn't needed in the scratch buffer. But It's suggested in this comment: #1382 (comment) .emacs
GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, cairo version 1.17.3) of 2020-08-28 |
Thanks for your efforts @duianto! Would be good to double-check the replacement macro is being called. I think just recompiling everything won't work, because when As a more fail-safe test, try saving the following in a file, say, "evil-with-undo-test.el", then byte-compile and load it:
When you run your recipe for reproducing the error, you should see the "In replacement `evil-with-undo'" message in the *Messages* buffer. If it's not there, it means the new macro isn't being used. If it is there, confirming the new macro is being used, and you still see the error, then I'll have to figure out how to reproduce this new case. Just tested again following the above procedure, and the error is definitely gone on my system. |
Ah, occurs to me that I had also made some local changes to |
I copied the contents of the current file: Overwrote the local file: Removed: Created a new file in:
Started Emacs. It complained that it couldn't find Saw that it now says:
Installed the package: Restarted Emacs.
When following the reproduction steps:
The first
The second
The
The same thing is observed with or without calling |
Thanks @duianto - I can reproduce this now. The macro change fixed one bug: To fix this one, I'll have to figure out what |
Hmm, on a side note, I think it might be worth making I realize I gotta rebind the combination to the appropriate function of |
Perhaps undo-tree mode could override the |
You don't have to rebind anything to use undo-tree: it installs a command remapping from
It already does override it, and always has done, using the appropriate Emacs mechanism (command remapping). The undo-tree package can't redefine the The only(*) way to call the vanilla (*) Unless you go to strenuous efforts to bind To be clear, Evil's But the buggy implementation will work OK most of the time. It takes a subtle combination of circumstances to trigger the bug: you need an undo-tree command to get called just before It's "just" a bug that needs fixing in evil-mode. |
Ah, I see, thank you for elaboration |
OK, I think this might be as simple as making Same proviso as before: I'm not certain what the expected behaviour should be. But loading the following code at least makes the "Unrecognized entry" error go away for me in @duianto's example:
|
I'm still getting the
The contents of
The file was loaded on Emacs startup:
|
@duianto I think this is because you're not setting the Could you try again, adding
immediately before the |
Confirmed. With only: With: (setq evil-undo-system 'undo-tree)
(evil-set-undo-system 'undo-tree) or just this single line: (custom-set-variables '(evil-undo-system 'undo-tree)) source: Now there is no Continuing to press
And after the fourth time Then the minibuffer shows:
Which most likely is expected. |
Addresses emacs-evil#1074 - evil-with-undo: nconc'ing onto front of buffer-undo-list here can corrupt buffer-undo-list when in undo-tree-mode in rare circumstances (see issue emacs-evil#1074 referenced above). Since evil-temporary-undo was always nil when executing @Body anyway, and reset to nil at end, other elisp code could never see a non-nil value for it anyway here. So we fix the nconc bug by simplifying the code, and getting rid of the redundant evil-temporary-undo juggling in the process. - evil-undo-pop: This function called `undo' directly from Elisp, which is almost always a bug in undo-tree-mode. Fix this by calling undo-tree-undo instead when in undo-tree-mode.
Addresses emacs-evil#1074 - evil-with-undo: nconc'ing onto front of buffer-undo-list here can corrupt buffer-undo-list when in undo-tree-mode in rare circumstances (see issue emacs-evil#1074). Leave standard undo machinery to work as usual when undo is enabled. Deal with disabled undo by temporarily enabling then disabling undo, and transferring any undo changes to evil-temporary-undo. - evil-undo-pop: This function called `undo' directly from Elisp, which is wrong when in undo-tree-mode. Fix this by calling undo-tree-undo instead when in undo-tree-mode.
Addresses emacs-evil#1074 - evil-with-undo: nconc'ing onto front of buffer-undo-list here can corrupt buffer-undo-list when in undo-tree-mode in rare circumstances (see issue emacs-evil#1074). Leave standard undo machinery to work as usual when undo is enabled. Deal with disabled undo by temporarily enabling then disabling undo, and transferring any undo changes to evil-temporary-undo. - evil-undo-pop: This function called `undo' directly from Elisp, which is wrong when in undo-tree-mode. Fix this by calling undo-tree-undo instead when in undo-tree-mode. Co-authored-by: Axel Forsman <axelsfor@gmail.com>
Addresses emacs-evil#1074 - evil-with-undo: nconc'ing onto front of buffer-undo-list here can corrupt buffer-undo-list when in undo-tree-mode in rare circumstances (see issue emacs-evil#1074). Leave standard undo machinery to work as usual when undo is enabled. Deal with disabled undo by temporarily enabling then disabling undo, and transferring any undo changes to evil-temporary-undo. - evil-undo-pop: This function called `undo' directly from Elisp, which is wrong when in undo-tree-mode. Fix this by calling undo-tree-undo instead when in undo-tree-mode. Co-authored-by: Axel Forsman <axelsfor@gmail.com>
Addresses emacs-evil#1074 - evil-with-undo: nconc'ing onto front of buffer-undo-list here can corrupt buffer-undo-list when in undo-tree-mode in rare circumstances (see issue emacs-evil#1074). Leave standard undo machinery to work as usual when undo is enabled. Deal with disabled undo by temporarily enabling then disabling undo, and transferring any undo changes to evil-temporary-undo. - evil-undo-pop: This function called `undo' directly from Elisp, which is wrong when in undo-tree-mode. Fix this by calling undo-tree-undo instead when in undo-tree-mode. Co-authored-by: Axel Forsman <axelsfor@gmail.com>
Addresses #1074 - evil-with-undo: nconc'ing onto front of buffer-undo-list here can corrupt buffer-undo-list when in undo-tree-mode in rare circumstances (see issue #1074). Leave standard undo machinery to work as usual when undo is enabled. Deal with disabled undo by temporarily enabling then disabling undo, and transferring any undo changes to evil-temporary-undo. - evil-undo-pop: This function called `undo' directly from Elisp, which is wrong when in undo-tree-mode. Fix this by calling undo-tree-undo instead when in undo-tree-mode. Co-authored-by: Axel Forsman <axelsfor@gmail.com>
Issue
Undo tree is an undo package that cannot keep undos.
Environment
Emacs version: Emacs 26.1.50
Operating System: Manjaro (current)
Evil version: Evil version 1.2.13
Evil installation type: MELP
Graphical/Terminal: Graphical
Tested in a
make emacs
session (see CONTRIBUTING.md): YesUndo configurations:
Reproduction steps
Expected behavior
You should be able to undo and/or redo every single change
Actual behavior
When it works, I'm able to undo 5 changes at the most. Half the time I can't undo anything at all. Sometimes I get the message
unrecognized entry in undo list undo-tree-canary
while I'm performing the undo.Further notes
It is not just me:
https://old.reddit.com/r/emacs/comments/85t95p/undo_tree_unrecognized_entry_in_undo_list/
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16523
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16377
https://lists.ourproject.org/pipermail/implementations-list/2014-November/002091.html
syl20bnr/spacemacs#298
syl20bnr/spacemacs#9903
I also must add that I had this same problem before with entirely different configurations, other versions of Emacs and operating systems.
The text was updated successfully, but these errors were encountered: