aboutsummaryrefslogtreecommitdiffstats
path: root/man
diff options
context:
space:
mode:
authorLuc Teirlinck <[email protected]>2005-01-31 23:18:45 +0000
committerLuc Teirlinck <[email protected]>2005-01-31 23:18:45 +0000
commit23c5319c0ef847f0db8121fc4d435d47359a163d (patch)
treeac1f6f6cdc954d4247d87be531ab5267164e9cf6 /man
parentfb89c330967ec70bb2cfc5d0af0b440fffbe29df (diff)
(Undo): Update description of `undo-outer-limit'.
Diffstat (limited to 'man')
-rw-r--r--man/basic.texi14
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