procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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.
This commit is contained in:
Dmitry Antipov 2014-08-27 14:51:21 +04:00
parent 7fb78a081b
commit 28e0124dd0
6 changed files with 23 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/lispref/ChangeLog
View file

@ -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.

7
doc/lispref/eval.texi
View file

@ -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

4
lisp/ChangeLog
View file

@ -1,3 +1,7 @@
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.

2
lisp/startup.el
View file

@ -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

4
src/ChangeLog
View file

@ -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>

8
src/keyboard.c
View file

@ -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");