# HG changeset patch
# User Luc Teirlinck <teirllm@auburn.edu>
# Date 1107213525 0
# Node ID 9d3ae9d4372d9a4e46f918cd321e38b238b22a53
# Parent  942539e5cf4e509693ab08e5672efbda35d53078
(Undo): Update description of `undo-outer-limit'.

diff -r 942539e5cf4e -r 9d3ae9d4372d man/basic.texi
--- a/man/basic.texi	Mon Jan 31 23:17:42 2005 +0000
+++ b/man/basic.texi	Mon Jan 31 23:18:45 2005 +0000
@@ -399,13 +399,13 @@
 
   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