bug#43138: Stack overflow in emacs 27 because of preloading emacs-seq

[Mark H Weaver <mhw@netris.org>]

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.

> 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