emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debugging "Lisp nesting exceeds max-lisp-eval-dept" error??


From: Martin Maechler
Subject: Re: debugging "Lisp nesting exceeds max-lisp-eval-dept" error??
Date: Wed, 31 Aug 2005 08:42:54 +0200

>>>>> "Stefan" == Stefan Monnier <address@hidden>
>>>>>     on Tue, 30 Aug 2005 22:50:47 -0400 writes:

    >>> Since lazy-lock is now obsolete, perhaps we should
    >>> simply redefine turn-on-lazy-lock as a no-op, so that it
    >>> won't do any harm.

    >> I think that making such a change on the basis that
    >> lazy-lock is obsolete is a bad idea.

    >> Apparently it is not merely inferior--it seems it doesn't
    >> work at all.

    Stefan> lazy-lock works OK.  The OP's problem has to do with
    Stefan> some details of how he turns it on.

yes, indeed.  I had "legacy" code in our group wide default.el
which has been working fine, maybe since emacs 19.x, and which
has amounted to the equivalent of the commandline (thanks to Chris Moore)

  emacs -Q --eval="
     (progn (setq debug-on-error t)
            (add-hook 'font-lock-mode-hook 'turn-on-lazy-lock)
            (global-font-lock-mode t))"

which lead to an infinite loop.

Ideally this should give a warning message to the user telling
her about jit-lock-mode and/or how to properly use lazy-lock if
that's really wanted inspite of its obsoleteness.

A propos obsolete / "remove completely" :

  I would favor a scheme where things that were fully working in
  emacs 21, are still there and working in emacs 22 and only
  completely removed in emacs 23.

Martin Maechler, ETH Zurich




reply via email to

[Prev in Thread] Current Thread [Next in Thread]