GNU bug report logs - #31793
26.1; (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31793 in the body.
You can then email your comments to 31793 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
Date: Tue, 12 Jun 2018 10:32:16 +0800

[Message part 1 (text/plain, inline)]

I was reading news in GNUS and suddenly emacs started echoing in the
minibuffer:

   Error in post-command-hook (global-eldoc-mode-check-buffers): (error "Variable binding depth exceeds max-specpdl-size")

After that I could not M-x or M-: or did much to investigate, only able
to copy the last part of *Messages* to a file (attached). Not sure if
this is useful.

But this bug might be interesting. It is new. A max-specpdl-size
automatically popped up while I was idly reading in GNUS.

[k.txt (text/plain, attachment)]

Message #8 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: 31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
Date: Tue, 12 Jun 2018 12:43:06 +0800

Get this same issue a second time also reading in GNUS. I'll have the
faulty emacs session available for a short while. If someone knows how
to get more info on what's wrong, I can try and get it.

I am sending this on 25.3.

Message #11 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: 31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
Date: Tue, 12 Jun 2018 12:59:32 +0800

[Message part 1 (text/plain, inline)]

On 2018-06-12 12:43 +0800, Leo Liu wrote:
> Get this same issue a second time also reading in GNUS. I'll have the
> faulty emacs session available for a short while. If someone knows how
> to get more info on what's wrong, I can try and get it.

The session crashed instead. I was trying to increase max-specpdl-size
and max-lisp-eval-depth from emacsclient -e. The crash report from the
OS is attached.

[bug.crash (text/plain, attachment)]

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org,Leo Liu <sdl.web <at> gmail.com>,31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds	‘max-lisp-eval-depth’")
Date: Tue, 12 Jun 2018 08:04:20 +0300

On June 12, 2018 7:43:06 AM GMT+03:00, Leo Liu <sdl.web <at> gmail.com> wrote:
> Get this same issue a second time also reading in GNUS. I'll have the
> faulty emacs session available for a short while. If someone knows how
> to get more info on what's wrong, I can try and get it.
> 
> I am sending this on 25.3.

Can you attach a debugger and produce a backtrace?  The
Lisp backtrace is also important, and the xbacktrace
command in the debugger should produce it.

Let us know if you need more detailed instructions.

Thanks.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org,Leo Liu <sdl.web <at> gmail.com>,31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds	‘max-lisp-eval-depth’")
Date: Tue, 12 Jun 2018 08:21:27 +0300

On June 12, 2018 7:59:32 AM GMT+03:00, Leo Liu <sdl.web <at> gmail.com> wrote:
> On 2018-06-12 12:43 +0800, Leo Liu wrote:
> > Get this same issue a second time also reading in GNUS. I'll have
> the
> > faulty emacs session available for a short while. If someone knows
> how
> > to get more info on what's wrong, I can try and get it.
> 
> The session crashed instead. I was trying to increase max-specpdl-size
> and max-lisp-eval-depth from emacsclient -e. The crash report from the
> OS is attached.

Ugh, macOS...  This means no xbacktrace and no other GDB
wizardry...

Well, I think the most important thing is to produce a Lisp
backtrace from the error.

Message #26 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds	‘max-lisp-eval-depth’")
Date: Tue, 12 Jun 2018 13:24:48 +0800

On 2018-06-12 08:04 +0300, Eli Zaretskii wrote:
> Can you attach a debugger and produce a backtrace? The Lisp backtrace
> is also important, and the xbacktrace command in the debugger should
> produce it.

Thanks. Will see what I can do. Attaching gdb to processes is becoming
more difficult with new macOS.

Leo

Message #29 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds	‘max-lisp-eval-depth’")
Date: Tue, 12 Jun 2018 16:46:11 +0800

[Message part 1 (text/plain, inline)]

On 2018-06-12 08:21 +0300, Eli Zaretskii wrote:
> Ugh, macOS...  This means no xbacktrace and no other GDB
> wizardry...

Indeed.

> Well, I think the most important thing is to produce a Lisp
> backtrace from the error.

Turns out 26.1 cannot load a version of python.el (by dave love) that I
have in my site-lisp.

1. emacs -Q -l python.el
2. M-x python-mode

,----[ error ]
| Variable binding depth exceeds max-specpdl-size
| Error in post-command-hook (global-eldoc-mode-check-buffers): (error "Variable binding depth exceeds max-specpdl-size")
`----

Gnus was just loading python-mode to fontify some code in an article.

[python.el (application/emacs-lisp, attachment)]

Message #32 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: John Shahid <jvshahid <at> gmail.com>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds
 ‘max-lisp-eval-depth’")
Date: Sat, 23 Jun 2018 15:47:11 +0000

[Message part 1 (text/plain, inline)]

Leo Liu <sdl.web <at> gmail.com> writes:

> On 2018-06-12 08:21 +0300, Eli Zaretskii wrote:
>> Ugh, macOS...  This means no xbacktrace and no other GDB
>> wizardry...
>
> Indeed.
>
>> Well, I think the most important thing is to produce a Lisp
>> backtrace from the error.
>
> Turns out 26.1 cannot load a version of python.el (by dave love) that I
> have in my site-lisp.
>
> 1. emacs -Q -l python.el
> 2. M-x python-mode
>
> ,----[ error ]
> | Variable binding depth exceeds max-specpdl-size
> | Error in post-command-hook (global-eldoc-mode-check-buffers): (error "Variable binding depth exceeds max-specpdl-size")
> `----
>
> Gnus was just loading python-mode to fontify some code in an article.

double posting since I sent the email only to Leo.

VVVV original email VVVV

That seems to be a result of converting `global-eldoc-mode' to use
`define-globalized-minor-mode' in 2349f. The recursive call seems to be
a result of the following sequence of calls:

1. python-mode is enabled which adds an eldoc-mode-hook
2. eldoc-mode is turned on in the buffer triggering python's
eldoc-mode-hook
3. python-mode hook will start an inferior process which in turn trigger
,MODE-enable-in-buffers
4. ,MODE-enable-in-buffers will go over the list again trying to enable
eldoc-mode

The problem is in step 4. The eldoc-global-mode buffer list isn't reset
in step 2. Step 4 will try to enabe the mode for the same buffer and
start a sequence of calls at 2. I was able to fix this problem by
setting the buffer-list to nil inside ,MODE-enable-in-buffers. I
attached a patch below.

[0001-avoid-turning-on-the-global-minor-mode-recursively.patch (text/x-diff, inline)]

From 9f6bb1c2d9cac8ccea129242d6977bc848b3f715 Mon Sep 17 00:00:00 2001
From: John Shahid <jvshahid <at> gmail.com>
Date: Sat, 23 Jun 2018 11:12:44 -0400
Subject: [PATCH] avoid turning on the global-minor-mode recursively

* lisp/emacs-lisp/easy-mmode.el (define-globalized-minor-mode): reset
  the buffer-list inside ,MODE-enable-in-buffers to avoid enabling the
  mode recursively
---
 lisp/emacs-lisp/easy-mmode.el | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
index a81b6fefb2..d363634236 100644
--- a/lisp/emacs-lisp/easy-mmode.el
+++ b/lisp/emacs-lisp/easy-mmode.el
@@ -457,7 +457,9 @@ define-globalized-minor-mode
 
        ;; The function that calls TURN-ON in each buffer.
        (defun ,MODE-enable-in-buffers ()
-	 (dolist (buf ,MODE-buffers)
+         (let ((buffers ,MODE-buffers))
+           (setq ,MODE-buffers nil)
+           (dolist (buf buffers)
 	   (when (buffer-live-p buf)
 	     (with-current-buffer buf
                (unless ,MODE-set-explicitly
@@ -467,12 +469,11 @@ define-globalized-minor-mode
 			 (,mode -1)
 			 (funcall #',turn-on))
 		     (funcall #',turn-on))))
-	       (setq ,MODE-major-mode major-mode)))))
+                 (setq ,MODE-major-mode major-mode))))))
        (put ',MODE-enable-in-buffers 'definition-name ',global-mode)
 
        (defun ,MODE-check-buffers ()
 	 (,MODE-enable-in-buffers)
-	 (setq ,MODE-buffers nil)
 	 (remove-hook 'post-command-hook ',MODE-check-buffers))
        (put ',MODE-check-buffers 'definition-name ',global-mode)
 
-- 
2.17.1

Message #35 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Leo Liu <sdl.web <at> gmail.com>
To: John Shahid <jvshahid <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
Date: Sun, 24 Jun 2018 16:27:28 +0800

On 2018-06-23 15:47 +0000, John Shahid wrote:
> That seems to be a result of converting `global-eldoc-mode' to use
> `define-globalized-minor-mode' in 2349f.

Do you happen to know why post-command-hook doesn't protect itself from
this error?

,----[ post-command-hook ]
| If an unhandled error happens in running this hook, the function in
| which the error occurred is unconditionally removed, since otherwise
| the error might happen repeatedly and make Emacs nonfunctional.
`----

This bug looks very serious because having to kill -9 emacs is serious.

Leo

Message #38 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: John Shahid <jvshahid <at> gmail.com>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds
 ‘max-lisp-eval-depth’")
Date: Mon, 25 Jun 2018 13:59:13 +0000

Leo Liu <sdl.web <at> gmail.com> writes:

> On 2018-06-23 15:47 +0000, John Shahid wrote:
>> That seems to be a result of converting `global-eldoc-mode' to use
>> `define-globalized-minor-mode' in 2349f.
>
> Do you happen to know why post-command-hook doesn't protect itself from
> this error?

This is due to the globalized minor mode re-adding itself to the
`post-command-hook' in `,MODE-cmhh'. This only happens when the
major-mode changes in some buffer. In other words, you will run into
this only when trying to switch buffers or use the minibuffer. You can
still navigate the file, i.e. `next-line' is usually fine for me.

> This bug looks very serious because having to kill -9 emacs is
> serious.

I agree, but I can't think of a better way to avoid this problem aside
from the patch I attached earlier.

cheers,

-js

Message #41 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org, John Shahid <jvshahid <at> gmail.com>
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
Date: Mon, 25 Jun 2018 12:24:06 -0400

On 24 June 2018 at 04:27, Leo Liu <sdl.web <at> gmail.com> wrote:

> This bug looks very serious because having to kill -9 emacs is serious.

I was able to recover by typing into the buffer "(fundamental-mode)"
and then C-x C-e.

Message #44 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: John Shahid <jvshahid <at> gmail.com>
To: Leo Liu <sdl.web <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds
 ‘max-lisp-eval-depth’")
Date: Tue, 03 Jul 2018 16:43:38 +0000

[Message part 1 (text/plain, inline)]

John Shahid <jvshahid <at> gmail.com> writes:

> Leo Liu <sdl.web <at> gmail.com> writes:
>
>> On 2018-06-12 08:21 +0300, Eli Zaretskii wrote:
>>> Ugh, macOS...  This means no xbacktrace and no other GDB
>>> wizardry...
>>
>> Indeed.
>>
>>> Well, I think the most important thing is to produce a Lisp
>>> backtrace from the error.
>>
>> Turns out 26.1 cannot load a version of python.el (by dave love) that I
>> have in my site-lisp.
>>
>> 1. emacs -Q -l python.el
>> 2. M-x python-mode
>>
>> ,----[ error ]
>> | Variable binding depth exceeds max-specpdl-size
>> | Error in post-command-hook (global-eldoc-mode-check-buffers): (error "Variable binding depth exceeds max-specpdl-size")
>> `----
>>
>> Gnus was just loading python-mode to fontify some code in an article.
>
> double posting since I sent the email only to Leo.
>
> VVVV original email VVVV
>
> That seems to be a result of converting `global-eldoc-mode' to use
> `define-globalized-minor-mode' in 2349f. The recursive call seems to be
> a result of the following sequence of calls:
>
> 1. python-mode is enabled which adds an eldoc-mode-hook
> 2. eldoc-mode is turned on in the buffer triggering python's
> eldoc-mode-hook
> 3. python-mode hook will start an inferior process which in turn trigger
> ,MODE-enable-in-buffers
> 4. ,MODE-enable-in-buffers will go over the list again trying to enable
> eldoc-mode
>
> The problem is in step 4. The eldoc-global-mode buffer list isn't reset
> in step 2. Step 4 will try to enabe the mode for the same buffer and
> start a sequence of calls at 2. I was able to fix this problem by
> setting the buffer-list to nil inside ,MODE-enable-in-buffers. I
> attached a patch below.

Added the bug number to the changelog entry and attached a new patch.

[0001-Avoid-turning-on-the-global-minor-mode-recursively-B.patch (text/x-diff, inline)]

From 893e62ee7e3630c981adb3efa39ef409500d7657 Mon Sep 17 00:00:00 2001
From: John Shahid <jvshahid <at> gmail.com>
Date: Sat, 23 Jun 2018 11:12:44 -0400
Subject: [PATCH] Avoid turning on the global-minor-mode recursively
 (Bug#31793)

* lisp/emacs-lisp/easy-mmode.el (define-globalized-minor-mode): Reset
  the buffer-list inside ,MODE-enable-in-buffers to avoid enabling the
  mode recursively
---
 lisp/emacs-lisp/easy-mmode.el | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
index b83b53a8e5..648b88ca77 100644
--- a/lisp/emacs-lisp/easy-mmode.el
+++ b/lisp/emacs-lisp/easy-mmode.el
@@ -474,7 +474,9 @@ define-globalized-minor-mode
 
        ;; The function that calls TURN-ON in each buffer.
        (defun ,MODE-enable-in-buffers ()
-	 (dolist (buf ,MODE-buffers)
+         (let ((buffers ,MODE-buffers))
+           (setq ,MODE-buffers nil)
+           (dolist (buf buffers)
 	   (when (buffer-live-p buf)
 	     (with-current-buffer buf
                (unless ,MODE-set-explicitly
@@ -484,12 +486,11 @@ define-globalized-minor-mode
 			 (,mode -1)
 			 (funcall #',turn-on))
 		     (funcall #',turn-on))))
-	       (setq ,MODE-major-mode major-mode)))))
+                 (setq ,MODE-major-mode major-mode))))))
        (put ',MODE-enable-in-buffers 'definition-name ',global-mode)
 
        (defun ,MODE-check-buffers ()
 	 (,MODE-enable-in-buffers)
-	 (setq ,MODE-buffers nil)
 	 (remove-hook 'post-command-hook ',MODE-check-buffers))
        (put ',MODE-check-buffers 'definition-name ',global-mode)
 
-- 
2.18.0

Message #47 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: John Shahid <jvshahid <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Leo Liu <sdl.web <at> gmail.com>
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds
 ‘max-lisp-eval-depth’")
Date: Wed, 04 Jul 2018 18:38:40 -0400

John Shahid <jvshahid <at> gmail.com> writes:

>> That seems to be a result of converting `global-eldoc-mode' to use
>> `define-globalized-minor-mode' in 2349f. The recursive call seems to be
>> a result of the following sequence of calls:
>>
>> 1. python-mode is enabled which adds an eldoc-mode-hook
>> 2. eldoc-mode is turned on in the buffer triggering python's
>> eldoc-mode-hook
>> 3. python-mode hook will start an inferior process which in turn trigger
>> ,MODE-enable-in-buffers
>> 4. ,MODE-enable-in-buffers will go over the list again trying to enable
>> eldoc-mode
>>
>> The problem is in step 4. The eldoc-global-mode buffer list isn't reset
>> in step 2. Step 4 will try to enabe the mode for the same buffer and
>> start a sequence of calls at 2. I was able to fix this problem by
>> setting the buffer-list to nil inside ,MODE-enable-in-buffers. I
>> attached a patch below.

Looks good to me.  I guess there is some risk since we are modifying a
macro which affects a lot of modes, but when balanced against the "risk"
that we actually fix similar problems in those modes I think this should
go to emacs-26.

> Added the bug number to the changelog entry and attached a new patch.
>
>>From 893e62ee7e3630c981adb3efa39ef409500d7657 Mon Sep 17 00:00:00 2001
> From: John Shahid <jvshahid <at> gmail.com>
> Date: Sat, 23 Jun 2018 11:12:44 -0400
> Subject: [PATCH] Avoid turning on the global-minor-mode recursively
>  (Bug#31793)
>
> * lisp/emacs-lisp/easy-mmode.el (define-globalized-minor-mode): Reset
>   the buffer-list inside ,MODE-enable-in-buffers to avoid enabling the
>   mode recursively

I would drop that comma from the commit message though, it's not really
part of the variable name, it's only meaningful in the context of a
backquote (and you forgot the period at the end of the sentence).

Message #50 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org, jvshahid <at> gmail.com, sdl.web <at> gmail.com
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds
 ‘max-lisp-eval-depth’")
Date: Thu, 05 Jul 2018 16:59:01 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Leo Liu <sdl.web <at> gmail.com>,  31793 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 04 Jul 2018 18:38:40 -0400
> 
> >> The problem is in step 4. The eldoc-global-mode buffer list isn't reset
> >> in step 2. Step 4 will try to enabe the mode for the same buffer and
> >> start a sequence of calls at 2. I was able to fix this problem by
> >> setting the buffer-list to nil inside ,MODE-enable-in-buffers. I
> >> attached a patch below.
> 
> Looks good to me.  I guess there is some risk since we are modifying a
> macro which affects a lot of modes, but when balanced against the "risk"
> that we actually fix similar problems in those modes I think this should
> go to emacs-26.

OK, but please add a comment there explaining why we set the
MODE-buffers to nil.

> > Added the bug number to the changelog entry and attached a new patch.
> >
> >>From 893e62ee7e3630c981adb3efa39ef409500d7657 Mon Sep 17 00:00:00 2001
> > From: John Shahid <jvshahid <at> gmail.com>
> > Date: Sat, 23 Jun 2018 11:12:44 -0400
> > Subject: [PATCH] Avoid turning on the global-minor-mode recursively
> >  (Bug#31793)

It is better to add the bug number to the body of the log message,
not to the header, because the latter has only limited space.

> > * lisp/emacs-lisp/easy-mmode.el (define-globalized-minor-mode): Reset
> >   the buffer-list inside ,MODE-enable-in-buffers to avoid enabling the
> >   mode recursively
> 
> I would drop that comma from the commit message though, it's not really
> part of the variable name, it's only meaningful in the context of a
> backquote (and you forgot the period at the end of the sentence).

Agreed.

Thanks.

Message #53 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: John Shahid <jvshahid <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31793 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>,
 sdl.web <at> gmail.com
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds
 ‘max-lisp-eval-depth’")
Date: Thu, 05 Jul 2018 16:33:29 +0000

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Noam Postavsky <npostavs <at> gmail.com>
>> Cc: Leo Liu <sdl.web <at> gmail.com>,  31793 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>
>> Date: Wed, 04 Jul 2018 18:38:40 -0400
>>
>> >> The problem is in step 4. The eldoc-global-mode buffer list isn't reset
>> >> in step 2. Step 4 will try to enabe the mode for the same buffer and
>> >> start a sequence of calls at 2. I was able to fix this problem by
>> >> setting the buffer-list to nil inside ,MODE-enable-in-buffers. I
>> >> attached a patch below.
>>
>> Looks good to me.  I guess there is some risk since we are modifying a
>> macro which affects a lot of modes, but when balanced against the "risk"
>> that we actually fix similar problems in those modes I think this should
>> go to emacs-26.
>
> OK, but please add a comment there explaining why we set the
> MODE-buffers to nil.
>
>> > Added the bug number to the changelog entry and attached a new patch.
>> >
>> >>From 893e62ee7e3630c981adb3efa39ef409500d7657 Mon Sep 17 00:00:00 2001
>> > From: John Shahid <jvshahid <at> gmail.com>
>> > Date: Sat, 23 Jun 2018 11:12:44 -0400
>> > Subject: [PATCH] Avoid turning on the global-minor-mode recursively
>> >  (Bug#31793)
>
> It is better to add the bug number to the body of the log message,
> not to the header, because the latter has only limited space.
>
>> > * lisp/emacs-lisp/easy-mmode.el (define-globalized-minor-mode): Reset
>> >   the buffer-list inside ,MODE-enable-in-buffers to avoid enabling the
>> >   mode recursively
>>
>> I would drop that comma from the commit message though, it's not really
>> part of the variable name, it's only meaningful in the context of a
>> backquote (and you forgot the period at the end of the sentence).
>
> Agreed.

Thanks for taking a look and reviewing the patch. Attached a new patch
with the suggested changes.

Cheers,

[0001-Avoid-turning-on-the-global-minor-mode-recursively.patch (text/x-diff, inline)]

From b8de8143d74777f25c9ec6f867c040332de810c4 Mon Sep 17 00:00:00 2001
From: John Shahid <jvshahid <at> gmail.com>
Date: Sat, 23 Jun 2018 11:12:44 -0400
Subject: [PATCH] Avoid turning on the global-minor-mode recursively

* lisp/emacs-lisp/easy-mmode.el (define-globalized-minor-mode): Clear
  the buffer-list inside MODE-enable-in-buffers to avoid enabling the
  mode recursively.  (Bug#31793)
---
 lisp/emacs-lisp/easy-mmode.el | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
index b83b53a8e5..6bf657848c 100644
--- a/lisp/emacs-lisp/easy-mmode.el
+++ b/lisp/emacs-lisp/easy-mmode.el
@@ -474,7 +474,12 @@ define-globalized-minor-mode
 
        ;; The function that calls TURN-ON in each buffer.
        (defun ,MODE-enable-in-buffers ()
-	 (dolist (buf ,MODE-buffers)
+         (let ((buffers ,MODE-buffers))
+           ;; Clear MODE-buffers to avoid scanning the same list of
+           ;; buffers in recursive calls to MODE-enable-in-buffers.
+           ;; Otherwise it could lead to infinite recursion.
+           (setq ,MODE-buffers nil)
+           (dolist (buf buffers)
 	   (when (buffer-live-p buf)
 	     (with-current-buffer buf
                (unless ,MODE-set-explicitly
@@ -484,12 +489,11 @@ define-globalized-minor-mode
 			 (,mode -1)
 			 (funcall #',turn-on))
 		     (funcall #',turn-on))))
-	       (setq ,MODE-major-mode major-mode)))))
+                 (setq ,MODE-major-mode major-mode))))))
        (put ',MODE-enable-in-buffers 'definition-name ',global-mode)
 
        (defun ,MODE-check-buffers ()
 	 (,MODE-enable-in-buffers)
-	 (setq ,MODE-buffers nil)
 	 (remove-hook 'post-command-hook ',MODE-check-buffers))
        (put ',MODE-check-buffers 'definition-name ',global-mode)
 
-- 
2.18.0

Message #56 received at 31793 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: John Shahid <jvshahid <at> gmail.com>
Cc: 31793 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, sdl.web <at> gmail.com
Subject: Re: bug#31793: 26.1; (error "Lisp nesting exceeds
 ‘max-lisp-eval-depth’")
Date: Tue, 10 Jul 2018 08:17:45 -0400

tags 31793 fixed
close 31793 26.2
quit

John Shahid <jvshahid <at> gmail.com> writes:

> Thanks for taking a look and reviewing the patch. Attached a new patch
> with the suggested changes.

Pushed to emacs-26.

[1: 35e0305dc2]: 2018-07-10 08:13:39 -0400
  Avoid turning on the global-minor-mode recursively
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=35e0305dc2a57cea6fcb515db9e0b0f938daf53a

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.