diff options
author | Luc Teirlinck <[email protected]> | 2005-01-31 23:18:45 +0000 |
---|---|---|
committer | Luc Teirlinck <[email protected]> | 2005-01-31 23:18:45 +0000 |
commit | 23c5319c0ef847f0db8121fc4d435d47359a163d (patch) | |
tree | ac1f6f6cdc954d4247d87be531ab5267164e9cf6 /man | |
parent | fb89c330967ec70bb2cfc5d0af0b440fffbe29df (diff) |
(Undo): Update description of `undo-outer-limit'.
Diffstat (limited to 'man')
-rw-r--r-- | man/basic.texi | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/man/basic.texi b/man/basic.texi index c04d8cf914..29bf6d4e20 100644 --- a/man/basic.texi +++ b/man/basic.texi @@ -399,13 +399,13 @@ value of @code{undo-strong-limit} is 30000. Regardless of the values of those variables, the most recent change is never discarded unless it gets bigger than @code{undo-outer-limit} -(normally 300,000). At that point, Emacs asks whether to discard the -undo information even for the current command. (You also have the -option of quitting.) So there is normally no danger that garbage -collection occurring right after an unintentional large change might -prevent you from undoing it. But if you didn't expect the command -to create such large undo data, you can get rid of it and prevent -Emacs from running out of memory. +(normally 3,000,000). At that point, Emacs discards the undo data and +warns you about it. This is the only situation in which you can not +undo the last command. If this happens, you can increase the value of +@code{undo-outer-limit} to make it even less likely to happen in the +future. But if you didn't expect the command to create such large +undo data, then it is probably a bug and you should report it. +@xref{Bugs,, Reporting Bugs}. The reason the @code{undo} command has two keys, @kbd{C-x u} and @kbd{C-_}, set up to run it is that it is worthy of a single-character |