Revision: miles@gnu.org--gnu-2005/emacs--unicode--0--patch-10

Merge from emacs--cvs-trunk--0

Patches applied:

 * miles@gnu.org--gnu-2005/emacs--cvs-trunk--0--patch-59
 - miles@gnu.org--gnu-2005/emacs--cvs-trunk--0--patch-68
   Update from CVS

1 files changed, 7 insertions, 7 deletions

diff --git a/man/basic.texi b/man/basic.texi
index c04d8cf914c..29bf6d4e207 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