0

Intermittently, I have a problem where I start an undo-tree-mode with C-X u. And as soon as I hit C-p to do an undo, the undo-tree pane closes.

This has been happening for a long while now. It happens when I use Spacemacs master or develop and Emacs 25, 26, or 27. I've even changed my keyboard.

There are no error messages in the *messages* buffer.

If I toggle the select mode, I can continue my undo to completion.

I have not been able to repeat the issue on demand. I can not determine the conditions that trigger it. Its driving me crazy.

Any idea on what it is or how I could debug this?

  • 1
    The most likely suspect is the triggering of undo-tree-kill-visualizer, perhaps because you have accidentally pressed a regular key while in the working buffer when the visualizer buffer/window is open; or, perhaps you have undo-tree-auto-save-history in the working buffer and you have configured Emacs to auto-save the working buffer after an edit or on a timer or something. You could set up a message inside undo-tree-kill-visualizer and see if it is somehow being activated when the window suddenly closes and then check the *Messages* buffer. That function is also triggered by q. – lawlist Jul 26 '20 at 16:37
  • I finally got fed up enough to figure out how to do the experiment @lawlist suggested. I put a message in the function undo-tree-kill-visualizer and when the undo-tree visualizer aborts just from doing a CTRL-P or Up Arrow, the message from undo-tree-kill-visualizer does show up in messages as many multiple times. undo-tree-auto-save-history is nil. Don't know how to debug this further. – Robert J Berger Sep 7 '20 at 0:37
  • 1
    What you describe is not the default behavior, nor is it a commonly known bug. I have a couple of suggestions.... At the outset of undo-tree-kill-visualizer, place something like this (message "last-command (%s) | current-buffer (%s)" last-command (current-buffer)) and check the message buffer to see if the keyboard shortcut you actually typed was undo-tree-visualize-undo or undo-tree-visualize-redo and see which buffer you are in when the visual buffer closes unexpectedly. The other idea is to reduce your user-configuration to narrow down the possibilities of finding the problem. – lawlist Sep 7 '20 at 1:40
  • @lawlist : I put that message function at the top of undo-tree-kill-visualizer and got multiple instances of last-command (self-insert-command) | current-buffer (product.cljs) when the undo-tree aborts. (product.cljs was the buffer I was editing) Really appreciate your help, this has been driving me crazy for a long time. – Robert J Berger Sep 8 '20 at 4:42
  • 1
    undo-tree-visualize-undo and undo-tree-visualize-redo jump back and forth between the working/target buffer and the visualization buffer by using switch-to-buffer-other-window. This is a poor design, and should have been done using with-current-buffer. Perhaps you may have unwittingly advised switch-to-buffer-other-window, or one of the functions used by the former. A keystroke executed in the working/target buffer will cause the visualization buffer to be killed. I would have written those functions as follows: gist.github.com/lawlist/4765516cf58a1ccc1d11de63bacaff34 – lawlist Sep 8 '20 at 5:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.