GNU bug report logs - #43138
Stack overflow in emacs 27 because of preloading emacs-seq

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 43138 in the body.
You can then email your comments to 43138 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: Pierre Langlois <pierre.langlois <at> gmx.com>
To: Bug guix <bug-guix <at> gnu.org>
Subject: Stack overflow in emacs 27 because of preloading emacs-seq
Date: Mon, 31 Aug 2020 16:48:02 +0100

Hello Guix!

Since switching to emacs 27 I've been having issues starting it, seeing
lots of errors like 'Lisp nesting exceeds ‘max-lisp-eval-depth’' when
loading various packages such as magit, ivy, ...etc.

After quite a bit of troubleshooting I reduced it to the `emacs-seq`
package. So if you create an environment with both `emacs-seq` and say
`magit`:

```
$ guix environment --pure --ad-hoc emacs emacs-magit emacs-seq
[env] $ emacs -Q --debug-init --eval "(require 'magit)"
```

Then you get the stack overflow.

Doing some digging, I found this comment from `doom-emacs` that
describes what is happening: https://github.com/hlissner/doom-emacs/issues/1990#issuecomment-549140718

I'm not familiar with emacs' autoloading, so I'm not sure I understand
what's going on fully. However, it mentions that `emacs-seq` has been
included in emacs proper for a while.

So, what would be the best fix for this? Should we remove `emacs-seq`
entirely or try and patch it? Since we don't support previous versions
of emacs I don't know if we need it.

Thanks,
Pierre

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

From: Mark H Weaver <mhw <at> netris.org>
To: Pierre Langlois <pierre.langlois <at> gmx.com>
Cc: 43138 <at> debbugs.gnu.org
Subject: Re: bug#43138: Stack overflow in emacs 27 because of preloading
 emacs-seq
Date: Mon, 31 Aug 2020 16:34:58 -0400

Hi Pierre,

Pierre Langlois <pierre.langlois <at> gmx.com> writes:

> [...] However, it mentions that `emacs-seq` has been
> included in emacs proper for a while.
>
> So, what would be the best fix for this? Should we remove `emacs-seq`
> entirely or try and patch it? Since we don't support previous versions
> of emacs I don't know if we need it.

If 'emacs-seq' is included in Emacs 27, it seems to me that we should
just delete it, unless there's something I'm missing.

Thanks for investigating!

      Mark

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

From: Pierre Langlois <pierre.langlois <at> gmx.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Pierre Langlois <pierre.langlois <at> gmx.com>, 43138 <at> debbugs.gnu.org
Subject: Re: bug#43138: Stack overflow in emacs 27 because of preloading
 emacs-seq
Date: Mon, 31 Aug 2020 22:20:17 +0100

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

Hi Mark,

Mark H Weaver writes:

> Hi Pierre,
>
> Pierre Langlois <pierre.langlois <at> gmx.com> writes:
>
>> [...] However, it mentions that `emacs-seq` has been
>> included in emacs proper for a while.
>>
>> So, what would be the best fix for this? Should we remove `emacs-seq`
>> entirely or try and patch it? Since we don't support previous versions
>> of emacs I don't know if we need it.
>
> If 'emacs-seq' is included in Emacs 27, it seems to me that we should
> just delete it, unless there's something I'm missing.

Agreed, I was curious if there was another reason for needing it, since
I /believe/ it's been in emacs proper since 25, but emacs-seq was added
in to guix after that. I suspect it it's still listed as a dependency
for packages, even though it's not actually needed.

Anyways, I've reconfigured my system with the following patch to fix the
issue, let me know if that looks OK! The packages that depended on it
build just fine, although I don't use them directly -- I was pulling
emacs-seq from emacs-org-roam which depends on emacs-biblio, but I'm not
using this feature.

Oh, another thing, I wanted to warn potential users of emacs-seq with a
deprecation warning using (guix deprecation), like:

    ;; seq.el is included into emacs.
    (define-deprecated emacs-seq emacs)

It would be good to do that so somebody isn't tempted to re-add it when
it's listed a dependency.  But that triggers errors:

    error: emacs: unbound variable
    hint: Did you forget a `use-modules' form?

Am I using it wrong? The (gnu packages emacs) module is included of
course.

Thanks,
Pierre

[0001-gnu-Remove-emacs-seq-package.patch (text/x-patch, attachment)]

Message #16 received at 43138-done <at> debbugs.gnu.org (full text, mbox):

From: Pierre Langlois <pierre.langlois <at> gmx.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: Pierre Langlois <pierre.langlois <at> gmx.com>, 43138-done <at> debbugs.gnu.org
Subject: Re: bug#43138: Stack overflow in emacs 27 because of preloading
 emacs-seq
Date: Fri, 04 Sep 2020 12:30:53 +0100

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

Hi Mark,

Replying with the bug on CC, I didn't realise your last email didn't
include it. I assume that was a mistake?

Mark H Weaver writes:

> Hi Pierre,
>
> Pierre Langlois <pierre.langlois <at> gmx.com> writes:
>
>> Mark H Weaver writes:
>>
>>> If 'emacs-seq' is included in Emacs 27, it seems to me that we should
>>> just delete it, unless there's something I'm missing.
>>
>> Agreed, I was curious if there was another reason for needing it, since
>> I /believe/ it's been in emacs proper since 25, but emacs-seq was added
>> in to guix after that. I suspect it it's still listed as a dependency
>> for packages, even though it's not actually needed.
>
> It might be that the copy of 'emacs-seq' in Emacs 26 was relatively old,
> and that some users and other emacs packages wanted a newer version.  I
> guess that's the rationale for 'emacs-org', and I vaguely recall that we
> might have had an updated Gnus package in the past as well, for the same
> reason.
>
> Hopefully the version of 'emacs-seq' bundled with Emacs 27 is now
> sufficiently up-to-date.
>
>> Anyways, I've reconfigured my system with the following patch to fix the
>> issue, let me know if that looks OK!
>
> Except for a minor typo in the commit log "alongisde", looks good to me.
>
> Thank you!  I think you should go ahead and push it to 'master', since
> things are currently broken and this is certainly an improvement.  If
> there are remaining issues, they can be addressed in future commits.

OK, pushed to master with 852ae64e11ef9107afabbdb307770f946376addd ,
I'll close the bug as well, I suppose we can open new ones in case
problems arise later.

>
>> Oh, another thing, I wanted to warn potential users of emacs-seq with a
>> deprecation warning using (guix deprecation), like:
>>
>>     ;; seq.el is included into emacs.
>>     (define-deprecated emacs-seq emacs)
>
> It's a good thought, but I'm not sure if 'define-deprecated' is the
> right thing here.  This might be a question for Ludovic.
>
>> It would be good to do that so somebody isn't tempted to re-add it when
>> it's listed a dependency.  But that triggers errors:
>>
>>     error: emacs: unbound variable
>>     hint: Did you forget a `use-modules' form?
>>
>> Am I using it wrong? The (gnu packages emacs) module is included of
>> course.
>
> I guess that this is most likely caused by a cyclic dependency between
> the (gnu packages emacs) and (gnu packages emacs-xyz) modules.  When
> there's a cyclic dependency between modules, Guile cannot ensure that
> the definitions of imported modules are evaluated first.
>
> In this case, I guess that (define-deprecated emacs-seq emacs) is
> evaluated before the definition of 'emacs' is evaluated, and that it
> fails to cope with that.
>
> I wish that we didn't have any cyclic module dependencies, but at this
> point it would require a *major* reorganization of our package modules
> to avoid it.

Ouch, yeah that seems like the problem, I'll see if I can get it to work
as a follow-up, but it seems not really worth the effort :-).

Thanks!
Pierre

[signature.asc (application/pgp-signature, inline)]

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

From: Mark H Weaver <mhw <at> netris.org>
To: Pierre Langlois <pierre.langlois <at> gmx.com>
Subject: Re: bug#43138: Stack overflow in emacs 27 because of preloading
 emacs-seq
Date: Mon, 31 Aug 2020 18:51:13 -0400

Hi Pierre,

Pierre Langlois <pierre.langlois <at> gmx.com> writes:

> Mark H Weaver writes:
>
>> If 'emacs-seq' is included in Emacs 27, it seems to me that we should
>> just delete it, unless there's something I'm missing.
>
> Agreed, I was curious if there was another reason for needing it, since
> I /believe/ it's been in emacs proper since 25, but emacs-seq was added
> in to guix after that. I suspect it it's still listed as a dependency
> for packages, even though it's not actually needed.

It might be that the copy of 'emacs-seq' in Emacs 26 was relatively old,
and that some users and other emacs packages wanted a newer version.  I
guess that's the rationale for 'emacs-org', and I vaguely recall that we
might have had an updated Gnus package in the past as well, for the same
reason.

Hopefully the version of 'emacs-seq' bundled with Emacs 27 is now
sufficiently up-to-date.

> Anyways, I've reconfigured my system with the following patch to fix the
> issue, let me know if that looks OK!

Except for a minor typo in the commit log "alongisde", looks good to me.

Thank you!  I think you should go ahead and push it to 'master', since
things are currently broken and this is certainly an improvement.  If
there are remaining issues, they can be addressed in future commits.

> Oh, another thing, I wanted to warn potential users of emacs-seq with a
> deprecation warning using (guix deprecation), like:
>
>     ;; seq.el is included into emacs.
>     (define-deprecated emacs-seq emacs)

It's a good thought, but I'm not sure if 'define-deprecated' is the
right thing here.  This might be a question for Ludovic.

> It would be good to do that so somebody isn't tempted to re-add it when
> it's listed a dependency.  But that triggers errors:
>
>     error: emacs: unbound variable
>     hint: Did you forget a `use-modules' form?
>
> Am I using it wrong? The (gnu packages emacs) module is included of
> course.

I guess that this is most likely caused by a cyclic dependency between
the (gnu packages emacs) and (gnu packages emacs-xyz) modules.  When
there's a cyclic dependency between modules, Guile cannot ensure that
the definitions of imported modules are evaluated first.

In this case, I guess that (define-deprecated emacs-seq emacs) is
evaluated before the definition of 'emacs' is evaluated, and that it
fails to cope with that.

I wish that we didn't have any cyclic module dependencies, but at this
point it would require a *major* reorganization of our package modules
to avoid it.

     Thanks,
       Mark

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

From: Mark H Weaver <mhw <at> netris.org>
To: Pierre Langlois <pierre.langlois <at> gmx.com>
Cc: 43138 <at> debbugs.gnu.org
Subject: Re: bug#43138: Stack overflow in emacs 27 because of preloading
 emacs-seq
Date: Fri, 04 Sep 2020 09:23:26 -0400

Pierre Langlois <pierre.langlois <at> gmx.com> writes:
> Replying with the bug on CC, I didn't realise your last email didn't
> include it. I assume that was a mistake?

Indeed, my mistake.  I just resent my previous email to complete the
record for this bug.

> OK, pushed to master with 852ae64e11ef9107afabbdb307770f946376addd ,
> I'll close the bug as well, I suppose we can open new ones in case
> problems arise later.

Sounds good.  Thanks for taking care of this, Pierre!

      Mark

Previous Next

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