From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: debugging post command hook max-lisp-eval-depth Date: Mon, 18 Jun 2018 10:03:00 -0400 Message-ID: References: <87efh5uxkl.fsf@gmail.com> <87a7rtuh77.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1529330654 9143 195.159.176.226 (18 Jun 2018 14:04:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2018 14:04:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: help-gnu-emacs@gnu.org To: John Shahid Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jun 18 16:04:10 2018 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fUulN-0002GB-Hz for geh-help-gnu-emacs@m.gmane.org; Mon, 18 Jun 2018 16:04:09 +0200 Original-Received: from localhost ([::1]:34950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUunU-0008M1-KH for geh-help-gnu-emacs@m.gmane.org; Mon, 18 Jun 2018 10:06:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUukS-0006TK-14 for help-gnu-emacs@gnu.org; Mon, 18 Jun 2018 10:03:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fUukK-0006an-DX for help-gnu-emacs@gnu.org; Mon, 18 Jun 2018 10:03:12 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:44785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fUukK-0006Z9-73 for help-gnu-emacs@gnu.org; Mon, 18 Jun 2018 10:03:04 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w5IE3ULZ028391; Mon, 18 Jun 2018 10:03:31 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 15D866611F; Mon, 18 Jun 2018 10:03:00 -0400 (EDT) In-Reply-To: <87a7rtuh77.fsf@gmail.com> (John Shahid's message of "Sun, 17 Jun 2018 23:27:40 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6310=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6310> : inlines <6702> : streams <1790045> : uri <2660266> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:117198 Archived-At: >> 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". >> 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. 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