No further undo information

[agzam]

I'm sure this is an upstream issue, I'm posting it here hoping someone would shed a light to it

I use evil and undo things in NORMAL mode pressing u (nothing unusual).

I have noticed that lately, I'm hitting the point where it simply says No further undo information and the stuff is simply lost. It's not in undo-tree either. I know, there are various vars like undo-limit that can be tweaked, but I haven't changed anything in my config. And it seems lately I'm hitting the limit fairly often - like I'd make about 10-20 changes, try to undo and bam! see the message, which is very frustrating and strange.

Does anyone else have the same problem?

[duianto]

The last comment in this issue:
unrecognized entry in undo list undo-tree-canary #9903
said that disabling this variable has fixed an undo issue (it might not be the same as yours):

(setq undo-tree-enable-undo-in-region nil)

Here's some more info about the variable:

(setq undo-tree-enable-undo-in-region nil)

See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=16377#55

Quote from Dr. Cubitt:

No, the new error checking just helpfully revealed an existing bug in
undo-tree's undo-in-region support (which frankly has always been flaky,
as it's extraordinarily difficult to reliably reproduce undo
bugs). There's even an `undo-tree-enable-undo-in-region' toggle to
disable undo-in-region support, for exactly this reason. Probably I
should make it default to "off" for now.

source: emacs-evil/evil#1074 (comment)

I haven't read all of the links from those issues, but I noticed this comment: #774 (comment)

A new package https://github.com/jackkamm/undo-propose-el has been released and claims to be safer to use than undo-tree.

It might also be something to test.

[agzam]

Yeah I did find that issue and set the variable to nil, but I don't think it fixed it for me. I still feel I hit the limit too early, but at this point it's all just empirical observation, I don't have any proof that it was better and now it has gotten worse.

[agzam]

undo-propose seems to be nice, maybe even better than undo-tree but I'm afraid the latter is lodged in Spacemacs ecosystem and it wouldn't be very straightforward to replace one package with another, I might be wrong though.

[duianto]

There seems to be a newer version 0.6.6 of undo-tree than what's available on elpa (0.6.5) (where Spacemacs probably is pulling it from), there's more info here: #9903 (comment)

[duianto]

yuhan0 suggested a method for getting the latest version of undo-tree: #9903 (comment)

And it works, I just replacing the undo-tree package listing in:
+spacemacs/spacemacs-editing/packages.el

with:

(undo-tree :location (recipe
                      :fetcher git
                      :url "http://www.dr-qubit.org/git/undo-tree.git"
                      :branch "master"))

then I moved the current undo-tree-0.6.5 dir to another location (as a backup), and restarted.

Now undo-tree.el shows:

;; Version: 0.6.6
;; Package-Version: 20170706.1146

the old one showed:

;; Version: 0.6.5

and the latest changelog entry at the bottom:

;; 2013-12-28 Toby S. Cubitt tsc25@cantab.net
;;
;; * undo-tree: Update to version 0.6.5.

[agzam]

I am still having this annoying issue. Can someone publish a guide how to remove undo-tree from Spacemacs completely and maybe replace it with something that actually works.

[johnny-mh]

I have same issue.

[yyoncho]

Proposed workaround - put the following line in dotspacemacs/user-config.

  (global-undo-tree-mode -1)

This will disable undo-tree mode and it will fallback to native emacs undo-redo functionality. Source - http://ergoemacs.org/emacs/emacs_best_redo_mode.html

[practicalli-johnny]

Disabling undo-tree mode as in the message above does not resolve the problem. History is still lost, although perhaps not quite as much as with undo-tree-mode

[agzam]

This thing is utterly annoying. Can someone please suggest a workaround? Undo is one of the most important features of any editor and I it is clearly broken right now in Spacemacs. I don't understand how is it not the most pressing issue at the moment?

[agzam]

reddit discussion https://www.reddit.com/r/emacs/comments/bx82j3/somehow_my_undo_history_is_truncated_what_did_i/

[duianto]

Reproduction steps to encounter the issue: No further undo information

Copy this snippet:

(dotimes (_ 30)
  (insert "Aliquam erat volutpat.  Nunc eleifend leo vitae magna.  In id erat non orci commodo lobortis.  Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus.  Sed diam.  Praesent fermentum tempor tellus.  Nullam tempus.  Mauris ac felis vel velit tristique imperdiet.  Donec at pede.  Etiam vel neque nec dui dignissim bibendum.  Vivamus id enim.  Phasellus neque orci, porta a, aliquet quis, semper a, massa.  Phasellus purus.  Pellentesque tristique imperdiet tortor.  Nam euismod tellus id erat.")
  (fill-paragraph))

• Open a new buffer SPC b N n
• Type: a (with the evil editing style return to normal state ESC)
• Open the Eval: prompt: M-:
• Paste and run the copied snippet: C-y RET
  In this state the variable: SPC h d v buffer-undo-list seems to have 16414 undo states.

(nil
 (" " . -14546)
 (14545 . 14546)
 (" " . -14466)

...

 (" " . -93)
 (" " . -55)
 (" " . -24)
 (1 . 500))

• Undo u
  the buffer only contains the initial: a
  the buffer-undo-list variable contains: (nil undo-tree-canary)
• Try to undo u again

user-error: No further undo information

Reproduced in both Ubuntu 18.04.02 and Windows 10 Version 1803.

System Info 💻

• OS: gnu/linux
• Emacs: 27.0.50
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. 803d4e7)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(emacs-lisp git helm markdown multiple-cursors org spell-checking treemacs version-control)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD PDUMPER LCMS2 GMP

System Info 💻

• OS: windows-nt
• Emacs: 26.2
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. 803d4e7)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(autohotkey emacs-lisp git helm javascript markdown multiple-cursors org spell-checking syntax-checking treemacs version-control)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS THREADS LCMS2

[tsc25]

@duianto's comment is the first report I've seen of this widely-reported issue that includes steps to reproduce. Unfortunately, I can't reproduce with vanilla undo-tree (i.e. not using Spacemacs). Following the equivalent of @duianto's steps in vanilla Emacs+undo-tree results for me in an undo tree containing two nodes, one the empty buffer, the other the buffer with all the text inserted, as expected. Undo/redo worked perfectly.

I believe Spacemacs adds extra undo boundaries compared to vanilla Emacs (can someone confirm?). So I tried running this modified snippet:

(dotimes` (_ 30)
  (insert "Aliquam erat volutpat.  Nunc eleifend leo vitae magna.  In id erat non orci commodo lobortis.  Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus.  Sed diam.  Praesent fermentum tempor tellus.  Nullam tempus.  Mauris ac felis vel velit tristique imperdiet.  Donec at pede.  Etiam vel neque nec dui dignissim bibendum.  Vivamus id enim.  Phasellus neque orci, porta a, aliquet quis, semper a, massa.  Phasellus purus.  Pellentesque tristique imperdiet tortor.  Nam euismod tellus id erat.")
(fill-paragraph)
(undo-boundary))

No luck. This produced a linear undo tree containing 31 nodes, as expected. Undo/redo still worked perfectly.

Can anyone find steps to reproduce this issue without Spacemacs? If they could, I might finally be able to make some headway with figuring out this bug! If not, it could indicate the issue is to do with how Spacemacs integrates undo-tree, rather than with the undo-tree package per se.

-- Toby (undo-tree author+maintainer)

[duianto]

When agzam posted the link to the reddit thread, that talks about that it could be a garbage collection issue. Then I messaged the spacemacs maintainers about it, and syl20bnr responded:

Lately the undo bug happens very frequently on my installations using emacs 27
pretty annoying
since spacemacs triggers GC very often it would make sense that this is the cause

[duianto]

I seem to be able to reproduce the issue without Spacemacs, by starting Emacs without any configurations and only installing undo-tree.

With the Spacemacs .emacs.d directory renamed to .emacs.d_backup.

• runemacs.exe --quick
• paste and evaluate the melpa setup:

(require 'package)
(let* ((no-ssl (and (memq system-type '(windows-nt ms-dos))
		    (not (gnutls-available-p))))
       (proto (if no-ssl "http" "https")))
  ;; Comment/uncomment these two lines to enable/disable MELPA and MELPA Stable as desired
  (add-to-list 'package-archives (cons "melpa" (concat proto "://melpa.org/packages/")) t)
  ;;(add-to-list 'package-archives (cons "melpa-stable" (concat proto "://stable.melpa.org/packages/")) t)
  (when (< emacs-major-version 24)
    ;; For important compatibility libraries like cl-lib
    (add-to-list 'package-archives '("gnu" . (concat proto "://elpa.gnu.org/packages/")))))
(package-initialize)

• M-x eval-buffer
• M-x package-install undo-tree RET
• C-x b test RET`
• M-x undo-tree-mode RET
  checking C-h v buffer-undo-list RET shows that it's nil
• Type: a
• Copy this snippet to the clipboard:

(dotimes (_ 30)
  (insert "Aliquam erat volutpat.  Nunc eleifend leo vitae magna.  In id erat non orci commodo lobortis.  Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus.  Sed diam.  Praesent fermentum tempor tellus.  Nullam tempus.  Mauris ac felis vel velit tristique imperdiet.  Donec at pede.  Etiam vel neque nec dui dignissim bibendum.  Vivamus id enim.  Phasellus neque orci, porta a, aliquet quis, semper a, massa.  Phasellus purus.  Pellentesque tristique imperdiet tortor.  Nam euismod tellus id erat.")
  (fill-paragraph))

• Open the Eval: prompt: M-:
• Paste and run the snippet: C-y RET
  checking the variable again: C-h v M-p (select the previous minibuffer history item) RET
  switch to the help buffer C-x o, searching for C-s value: shows:

Value:
(nil
 (" " . -14883)
 (14882 . 14883)
 (" " . -14818)

...

switching back to the test buffer C-x o

• M-x undo-tree-undo RET
  only a is left in the buffer, undo-buffer-list shows the value as nil.
• M-x undo-tree-undo RET
  The messages buffer shows:

user-error: No further undo information

System info

GNU Emacs 26.2 (build 1, x86_64-w64-mingw32) of 2019-04-13
Windows 10 Version 1803 (OS Build 17134.829)

Also reproduced with:
GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2019-06-09
Ubuntu 18.04.2 LTS

[tsc25]

@duianto Thanks! I can reproduce this using your recipe. But this appears to be undo-tree behaving as expected.

The undo history is longer than undo-limit (and probably also one or more of the other limits, undo-strong-limit or undo-outer-limit). So emacs GC discards the oldest part of the undo history, which in this case consists of the insertion of "a". You can see exactly the same behaviour (i.e. just "a" left in the buffer and the "No further undo information" message) witthout undo-tree-mode, using vanilla emacs undo.

If you increase the values of undo-limit, undo-outer-limit, and undo-strong-limit you'll see you can undo all the way back to an empty buffer (both with vanilla undo, and with undo-tree).

[duianto]

Thanks for the clarification. Then we're back to Spacemacs being to aggressive with garbage collection as syl20bnr said.

[tsc25]

Indeed. It definitely seems like garbage collection is involved here. Depending on when GC kicks in, the history may get discarded before undo-tree sees it, or it may get incorporated into the tree. Undo-tree does its own history discarding when it gets too big. But because the way it stores the undo history is (sometimes) more efficient than vanilla emacs undo, it might sometimes keep more history than vanilla undo.

Spacemacs triggering GC more frequently would likely lead more often to emacs discarding undo history before undo-tree sees it. So that might explain why people seem to see this effect more often with Spacemacs.

But none of this is a bug. This is all intentional behaviour both of undo-tree and vanilla emacs undo. As documented in the manual, you can keep more undo history around by increasing the values of undo-limit, undo-strong-limit and undo-outer-limit.

It would be nice to think this misunderstanding of how emacs discards undo history explains all the reports of "No further undo information" with undo-tree. But I'm not sure. I need more recipes like yours that reproduce the observed behavour, before I can investigate and determine whether it's expected or not.

[agzam]

@duianto @tsc25 I can't appreciate you enough for going above and beyond to get to the bottom of this. I guess we can soon expect aforementioned vars to be tweaked in Spacemacs core, in the meantime, what would be the best defaults in your opinion? Can you provide struggling and disappointed users (such myself) with the instructions? Thank you!

[tsc25]

@agzam It's as much thanks to @duianto for putting in the hard work of finding a reproducible recipe.

The Emacs defaults for undo-limit etc. are (rightly) quite conservative: the defaults keep only ~80kb of undo history. On modern machines with plenty of RAM, it's probably safe to increase this substantially (though don't blame me if you start swapping :)

You can use M-x customize-variable undo-limit<ret> etc. to customize each of undo-limit, undo-strong-limit and undo-outer-limit to larger values (or set them directly in your .emacs if you don't like the customize interface).

Read the docstrings to understand the differences between these three settings. Basically, you'll want to set undo-limit to the number of bytes of undo history you want to keep around, and set undo-strong-limit and undo-outer-limit to somewhat larger values than undo-limit.

I'm not yet 100% convinced these settings are the whole story behind the issue of undo-tree losing history. But if the issue seems to goes away by increasing these settings for Spacemacs users, then I'll start to believe there was never any bug, and it was just the interaction between Spacemacs, GC and undo-tree happening to trigger more frequent undo history cleanup.

[duianto]

It might not be a garbage collection issue.

There's a variable called gc-done.

Accumulated number of garbage collections done.

I set the gc-cons-threshold to 1gB in .spacemacs

   dotspacemacs-gc-cons '(1000000000 0.1)

And replicated the steps.
Before: gc-done = 4
After: gc-done = 4

undo still shows No further undo information.

Update:

It's a to limited test. With regular use one will perform helm/ivy searches, spell/syntax check, etc., any of which could trigger garbage collection. So it's probably difficult to rule it out as a source.

[practicalli-johnny]

I increased the variable limit as suggested by @tsc25, by a factor of 10 and so far I havent lost any history (after several hours) or had the annoying no more history. I will see what happens over the next day or so.

In the dotspacemacs/user-config section of .spacemacs file, I have added the following

  ;; default in spacemacs is 80000
  (setq undo-limit 800000)
  
  ;; default in spacemacs is 120000
  (setq undo-strong-limit 12000000)
  
  ;; default in spacemacs is 12000000
  (setq undo-outer-limit 120000000)

[duianto]

@jr0cket That's great, thanks for testing.

Spacemacs uses the default Emacs values. Because they are the same without Spacemacs:
emacs --quick

If it works then I'm sure they can be increased in Spacemacs.

[duianto]

Another possible solution might be to double the .spacemacs garbage collection threshold variable, from 100MB to 200MB.

   dotspacemacs-gc-cons '(200000000 0.1)

This was suggested by an Emacs maintainer in this thread: https://www.reddit.com/r/emacs/comments/bg85qm/garbage_collector_magic_hack/eln27qh/

[tsc25]

Increasing gc-cons might be something you want to do anyway. But that's definitely not the right solution to undo history truncation. The right solution is to tell Emacs to keep more undo history.

GC is one of the opportunities Emacs uses to check undo-limit etc. and truncate undo history. (I have a suspicion it's not the only time Emacs checks undo-limit and truncates, due to your report above. I'm still testing undo-tree and grepping through Emacs c code...) But if the history accumulated in buffer-undo-tree exceeds undo-limit etc, then Emacs is supposed to truncate the undo history. Giving Emacs fewer opportunities to do so in the hope that undo-tree-mode will grab that history before Emacs gets the chance to is racy and unreliable. Also, undo-tree does its own truncation of the history in the undo tree, so it will still throw away anything over undo-limit. (Just that, due to the way undo-tree-mode stores undo history, it can sometimes store more history than vanilla Emacs undo before breaching the limits.)

[syl20bnr]

I pushed the settings from @jr0cket to the develop branch.
Commit dcb4da02a

[gambhiro]

I am reporting success. I haven't seen 'no further undo' for a while. First I've been using the custom settings, and 10 days ago I updated spacemacs from the develop branch.

[syl20bnr]

I'm reporting success too, I encountered it very easily before the new settings.