emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: brian powell <briangpowellms@gmail.com>
To: butz@sym.net
Cc: emacs-orgmode@gnu.org
Subject: Re: Lisp nesting exceeds `max-lisp-eval-depth'"
Date: Thu, 15 Sep 2011 09:30:04 -0400	[thread overview]
Message-ID: <CAFm0skFK8r2uqHAvYAeUU476Xf+XQ8Hno1paZpJ38nza+8avkA@mail.gmail.com> (raw)
In-Reply-To: <4E71BBE0.8090404@sym.net>

*"Variable: max-lisp-eval-depth
This variable defines the maximum depth allowed in calls to eval,
apply, and funcall before an error is signaled (with error message
"Lisp nesting exceeds max-lisp-eval-depth"). This limit, with the
associated error when it is exceeded, is one way that Lisp avoids
infinite recursion on an ill-defined function.
The depth limit counts internal uses of eval, apply, and funcall, such
as for calling the functions mentioned in Lisp expressions, and
recursive evaluation of function call arguments and function body
forms, as well as explicit calls in Lisp code.

The default value of this variable is 300. If you set it to a value
less than 100, Lisp will reset it to 100 if the given value is
reached. Entry to the Lisp debugger increases the value, if there is
little room left, to make sure the debugger itself has room to
execute.

max-specpdl-size provides another limit on nesting. See section 11.3
Local Variables."

**I think this is one weakness of ELISP vs. CommonLISP--but this is
"by design"; EMACS has always been focused on editing, so some
trade-offs are used, objects such as "buffers, windows, etc." are a
paramount part of the language--and recursion is handled slightly
differently, I believe this is done on purpose.

**Maybe try to set the max-lisp-eval-depth variable higher?

***Maybe something like (setq max-lisp-eval-depth 3000)

**Maybe load the common lisp module; which is always a good idea--but
this probably won't help, just an idea.


On Thu, Sep 15, 2011 at 4:48 AM, Martin Butz <butz@sym.net> wrote:
> Hello all,
>
> I get the following error message while using org-mode during the last weeks
> quite frequently (unfortunately I am not able to link it to an update of the
> installation of some lisp file); I can reproduce the behaviour by opening
> the agenda buffer (C-c a a) and trying to quit with "q"; this will open a
> new frame with the backtrace buffer and leave the agenda buffer in the other
> frame open.
>
> There are loads of other events, which trigger the same behaviour; can
> anybody give a hint how I can solve this rather annoying problem?
>
> Thanks in advance
> Martin
>
> ---- Backtrace --8<----------------------------------------------------
>
> Debugger entered--Lisp error: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>  (- (nth 2 edges) (nth 0 edges))
>  (let ((edges ...)) (- (nth 2 edges) (nth 0 edges)))
>  sr-speedbar-current-window-take-width()
>  (let ((win-width ...)) (if (and ... ... ...) (setq sr-speedbar-width
> win-width)))
>  sr-speedbar-remember-window-width()
>  old-delete-window(#<window 20 on *Org Agenda*>)
>
> ---- following lines are repeated several times--8<--------------------
>
>  (if (one-window-p t) (delete-frame) (old-delete-window (selected-window)))
>  (save-current-buffer (setq window (or window ...)) (select-window window)
> (if (one-window-p t) (delete-frame) (old-delete-window ...)))
>  ad-Orig-delete-window(#<window 20 on *Org Agenda*>)
>  old-delete-window(#<window 20 on *Org Agenda*>)
>
> ---- /following lines are repeated several times--8<-------------------
>
>  (if (one-window-p t) (delete-frame) (old-delete-window (selected-window)))
>  (save-current-buffer (setq window (or window ...)) (select-window window)
> (if (one-window-p t) (delete-frame) (old-delete-window ...)))
>  ad-Orig-delete-window(nil)
>  delete-window()
>  (and (not (eq org-agenda-window-setup ...)) (not (one-window-p))
> (delete-window))
>  (if (eq org-agenda-window-setup (quote other-frame)) (progn (kill-buffer
> buf) (org-agenda-reset-markers) (org-columns-remove-overlays) (setq
> org-agenda-archives-mode nil) (delete-frame)) (and (not ...) (not ...)
> (delete-window)) (kill-buffer buf) (org-agenda-reset-markers)
> (org-columns-remove-overlays) (setq org-agenda-archives-mode nil))
>  (let ((buf ...)) (if (eq org-agenda-window-setup ...) (progn ... ... ...
> ... ...) (and ... ... ...) (kill-buffer buf) (org-agenda-reset-markers)
> (org-columns-remove-overlays) (setq org-agenda-archives-mode nil)))
>  (if org-agenda-columns-active (org-columns-quit) (let (...) (if ... ... ...
> ... ... ... ...)) (and org-agenda-restore-windows-after-quit (not ...)
> org-pre-agenda-window-conf (set-window-configuration
> org-pre-agenda-window-conf)))
>  org-agenda-quit()
>  call-interactively(org-agenda-quit nil nil)
>
> ---- /Backtrace --8<---------------------------------------------------
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> sym.net  ||  butz & siefer gbr  ||  50670 koeln  ||  hansaring 78
> phone +49(0)221/3762591 -  twitter.com/symnet  - mail butz@sym.net
> ~~~~~~~~~~~~~~~~~~ www.sym.net | www.moodalis.de ~~~~~~~~~~~~~~~~
>
>

      parent reply	other threads:[~2011-09-15 13:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-15  8:48 Lisp nesting exceeds `max-lisp-eval-depth'" Martin Butz
2011-09-15  9:36 ` Olaf Dietsche
     [not found]   ` <4E71C870.5080900@sym.net>
2011-09-15 10:46     ` Olaf Dietsche
2011-09-15 13:30 ` brian powell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFm0skFK8r2uqHAvYAeUU476Xf+XQ8Hno1paZpJ38nza+8avkA@mail.gmail.com \
    --to=briangpowellms@gmail.com \
    --cc=butz@sym.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).