[Emacs-diffs] trunk r117749: * src/keyboard.c (Vtop_level_message): Rename to

[Dmitry Antipov]

------------------------------------------------------------
revno: 117749
revision-id: address@hidden
parent: address@hidden
committer: Dmitry Antipov <address@hidden>
branch nick: trunk
timestamp: Wed 2014-08-27 14:51:21 +0400
message:
  * 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.
modified:
  doc/lispref/ChangeLog          changelog-20091113204419-o5vbwnq5f7feedwu-6155
  doc/lispref/eval.texi          eval.texi-20091113204419-o5vbwnq5f7feedwu-6178
  lisp/ChangeLog                 changelog-20091113204419-o5vbwnq5f7feedwu-1432
  lisp/startup.el                startup.el-20091113204419-o5vbwnq5f7feedwu-260
  src/ChangeLog                  changelog-20091113204419-o5vbwnq5f7feedwu-1438
  src/keyboard.c                 keyboard.c-20091113204419-o5vbwnq5f7feedwu-449

=== modified file 'doc/lispref/ChangeLog'
--- a/doc/lispref/ChangeLog     2014-07-11 12:49:49 +0000
+++ b/doc/lispref/ChangeLog     2014-08-27 10:51:21 +0000
@@ -1,3 +1,7 @@
+2014-08-27  Dmitry Antipov  <address@hidden>
+
+       * eval.texi (Eval): Mention possible recovery from stack overflow.
+
 2014-07-11  Eli Zaretskii  <address@hidden>
 
        * internals.texi (Garbage Collection): Fix last change.

=== modified file 'doc/lispref/eval.texi'
--- a/doc/lispref/eval.texi     2014-01-01 07:43:34 +0000
+++ b/doc/lispref/eval.texi     2014-08-27 10:51:21 +0000
@@ -805,7 +805,12 @@
 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

=== modified file 'lisp/ChangeLog'
--- a/lisp/ChangeLog    2014-08-26 17:55:07 +0000
+++ b/lisp/ChangeLog    2014-08-27 10:51:21 +0000
@@ -1,3 +1,7 @@
+2014-08-27  Dmitry Antipov  <address@hidden>
+
+       * startup.el (normal-top-level): Now use internal--top-level-message.
+
 2014-08-26  Dmitry Antipov  <address@hidden>
 
        * startup.el (normal-top-level): Use top-level-message.

=== modified file 'lisp/startup.el'
--- a/lisp/startup.el   2014-08-26 06:25:59 +0000
+++ b/lisp/startup.el   2014-08-27 10:51:21 +0000
@@ -497,7 +497,7 @@
 reads the initialization files, etc.
 It is the default value of the variable `top-level'."
   (if command-line-processed
-      (message top-level-message)
+      (message internal--top-level-message)
     (setq command-line-processed t)
 
     ;; Look in each dir in load-path for a subdirs.el file.  If we

=== modified file 'src/ChangeLog'
--- a/src/ChangeLog     2014-08-27 04:15:20 +0000
+++ b/src/ChangeLog     2014-08-27 10:51:21 +0000
@@ -6,6 +6,10 @@
        (handle_sigsegv): Check whether we really crash somewhere near
        to stack boundary, and handle fatal signal as usual if not.
        (init_sigsegv): Adjust accordingly.
+       * 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.
 
 2014-08-26  Dmitry Antipov  <address@hidden>
 

=== modified file 'src/keyboard.c'
--- a/src/keyboard.c    2014-08-27 04:15:20 +0000
+++ b/src/keyboard.c    2014-08-27 10:51:21 +0000
@@ -1153,10 +1153,10 @@
     {
       /* Comes here from handle_sigsegv, see sysdep.c.  */
       init_eval ();
-      Vtop_level_message = recover_top_level_message;
+      Vinternal__top_level_message = recover_top_level_message;
     }
   else
-    Vtop_level_message = regular_top_level_message;
+    Vinternal__top_level_message = regular_top_level_message;
 #endif /* HAVE_STACK_OVERFLOW_HANDLING */
   if (command_loop_level > 0 || minibuf_level > 0)
     {
@@ -11029,9 +11029,9 @@
   recover_top_level_message
     = build_pure_c_string ("Re-entering top level after C stack overflow");
 #endif
-  DEFVAR_LISP ("top-level-message", Vtop_level_message,
+  DEFVAR_LISP ("internal--top-level-message", Vinternal__top_level_message,
               doc: /* Message displayed by `normal-top-level'.  */);
-  Vtop_level_message = regular_top_level_message;
+  Vinternal__top_level_message = regular_top_level_message;
 
   /* Tool-bars.  */
   DEFSYM (QCimage, ":image");