help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: debugging post command hook max-lisp-eval-depth


From: John Shahid
Subject: Re: debugging post command hook max-lisp-eval-depth
Date: Mon, 18 Jun 2018 12:33:36 -0400

On Mon, Jun 18, 2018, 10:03 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> Hmm... post-command-hook is run via `safe_run_hooks` which is supposed
> >> to try and catch errors such that when an error is caught the
> >> corresponding function is removed from post-command-hook.
> > I don't think there is a specific hook that is recursing infinitely. The
> > two I noticed in the error message were both global minor modes
> > (magit-file-mode & display-line-numbers).
>
> Hmm... I don't understand what you mean: when you say "I don't think
> there is a specific hook that is recursing infinitely" do you mean hook
> as in "post-command-hook" or in "one of the functions placed on
> post-command-hook"?
>
> Then you say "the two ... were global minor modes", but I fail to see
> how a "hook" can be a "minor mode".
>

Sorry, I meant functions placed on the hook.


> >> Of course, this is a just a mitigating factor, but it should prevent the
> >> problem you describe, except in those cases where the offending function
> >> is constantly re-added (e.g. by a pre-command-hook).
> > I think that's the case, `define-globalized-minor-mode' will add the
> > post-command-hook in MODE-cmhh.
>
> Now that I think about it, the message you get should say which hook
> function had an error, since the message is emitted with:
>
>   AUTO_STRING (format, "Error in %s (%S): %S");
>   Lisp_Object hook = args[0];
>   Lisp_Object fun = args[1];
>   CALLN (Fmessage, format, hook, fun, error);
>
> where `fun` is the function during which the error was signaled.
>

That's what I was trying to explain above. The function name in the error
message isn't consistent.


> So if you only get "Lisp nesting exceeds...", check your *Messages* and
> if even there you don't have the "Error in ... (...): ..." message, it
> means that the error was most likely signaled elsewhere than in
> post-command-hook.
>
>
>         Stefan
>


reply via email to

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