Commit 28e0124d authored by Dmitry Antipov's avatar Dmitry Antipov

* 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.
parent 7fb78a08
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.
......
......@@ -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
......
2014-08-27 Dmitry Antipov <dmantipov@yandex.ru>
* startup.el (normal-top-level): Now use internal--top-level-message.
2014-08-26 Dmitry Antipov <dmantipov@yandex.ru>
* startup.el (normal-top-level): Use top-level-message.
......
......@@ -497,7 +497,7 @@ It sets `command-line-processed', processes the command-line,
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
......
......@@ -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 <dmantipov@yandex.ru>
......
......@@ -1153,10 +1153,10 @@ command_loop (void)
{
/* 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 @@ syms_of_keyboard (void)
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");
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment