[Top][All Lists]

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

bug#43138: closed (Stack overflow in emacs 27 because of preloading emac

From: GNU bug Tracking System
Subject: bug#43138: closed (Stack overflow in emacs 27 because of preloading emacs-seq)
Date: Fri, 04 Sep 2020 11:31:02 +0000

Your message dated Fri, 04 Sep 2020 12:30:53 +0100
with message-id <87mu25srrm.fsf@gmx.com>
and subject line Re: bug#43138: Stack overflow in emacs 27 because of 
preloading emacs-seq
has caused the debbugs.gnu.org bug report #43138,
regarding Stack overflow in emacs 27 because of preloading emacs-seq
to be marked as done.

(If you believe you have received this mail in error, please contact

43138: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43138
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Stack overflow in emacs 27 because of preloading emacs-seq Date: Mon, 31 Aug 2020 16:48:02 +0100 User-agent: mu4e 1.4.13; emacs 27.1
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

$ 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: 

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.


--- End Message ---
--- Begin Message --- Subject: Re: bug#43138: Stack overflow in emacs 27 because of preloading emacs-seq Date: Fri, 04 Sep 2020 12:30:53 +0100 User-agent: mu4e 1.4.13; emacs 27.1
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@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 :-).


Attachment: signature.asc
Description: PGP signature

--- End Message ---

reply via email to

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