* src/keyboard.c (Vtop_level_message): Rename to

Vinternal__top_level_message, as suggested by Stefan Monnier in
http://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00493.html
All related users changed.
* lisp/startup.el (normal-top-level): Now use internal--top-level-message.
* doc/lispref/eval.texi (Eval): Mention possible recovery from stack overflow.

2 files changed, 10 insertions, 1 deletions

diff --git a/doc/lispref/ChangeLog b/doc/lispref/ChangeLog
index 58548077d3d..3719b223b35 100644
--- a/doc/lispref/ChangeLog
+++ b/doc/lispref/ChangeLog
@@ -1,3 +1,7 @@
+2014-08-27  Dmitry Antipov  <dmantipov@yandex.ru>
+
+        * eval.texi (Eval): Mention possible recovery from stack overflow.
+
 2014-07-11  Eli Zaretskii  <eliz@gnu.org>
 
         * internals.texi (Garbage Collection): Fix last change.
diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi
index 05250233b00..6ffc7db8abf 100644
--- a/doc/lispref/eval.texi
+++ b/doc/lispref/eval.texi
@@ -805,7 +805,12 @@ message @code{"Lisp nesting exceeds max-lisp-eval-depth"}).
 This limit, with the associated error when it is exceeded, is one way
 Emacs Lisp avoids infinite recursion on an ill-defined function.  If
 you increase the value of @code{max-lisp-eval-depth} too much, such
-code can cause stack overflow instead.
+code can cause stack overflow instead.  On some systems, this overflow
+can be handled.  In that case, normal Lisp evaluation is interrupted
+and control is transferred back to the top level command loop
+(@code{top-level}).  Note that there is no way to enter Emacs Lisp
+debugger in this situation.  @xref{Error Debugging}.
+
 @cindex Lisp nesting error
 
 The depth limit counts internal uses of @code{eval}, @code{apply}, and