bug#38309: Recent $EMACSLOADPATH changes crash gnome-session

[Maxim Cournoyer]

Hello Leo!

Leo Prikler <address@hidden> writes:

> Hi everyone,
>
> Am Dienstag, den 26.11.2019, 09:56 +0100 schrieb Ludovic Courtès: 
>> are we not going overboard with that big a environment variable? :-)
> I think I vaguely remember a related discussion about the Emacs build
> system adding the guix.d directory, which further worsens this problem
> [1].  Putting that aside however, $EMACSLOADPATH should not contain
> more than
> - $GUIX_PROFILE/share/emacs/$EMACS_VERSION/lisp
> - $GUIX_PROFILE/share/emacs/$EMACS_VERSION/site-lisp
> - $GUIX_PROFILE/share/emacs/site-lisp
> If I read (elisp)Library Search correctly, these directories each
> contain a file to add their subdirectories to the load-path variable.  
> This can be confirmed by searching in the store or through message-
> debugging.  It appears, however, that these files are not quite
> sufficient.  While the load-path is indeed modified, no autoloading
> occurs for files inside guix.d -- indeed, I doubt it would occur for
> any package, regardless of how we name it.

That's a precious find!  I could validate your findings.  The only place
we don't have a union of the Elisp directories (with a subdirs.el file)
is at build time, but in the event we'd stop producing guix.d the search
path would work natively there (as well as causing any newly installed
libraries to be found without any rescanning of directories).

> After further digging around, this appears to be a bug in guix-emacs. 
> Rather than using the load-path variable, it uses $EMACSLOADPATH
> directly via getenv.  I suggest either recursing into subdirectories as
> Emacs itself would or using load-path instead of reverse engineering
> it, preferring the latter if applicable.
>
> Now that this has been cleared up, a fix should be in reach.  First we
> would fix guix-emacs, then we can restrict $EMACSLOADPATH to the above
> three -- perhaps two, as the versioned site-lisp appears unused.

Neat!  I find that this works best when guix.d is removed, as otherwise

1) relying on the load-path would mean we'd have to restart Emacs when
installed new libraries under guix.d directories (to have subdirs.el to
its magic and add them to the load-path)

2) the emacs-build-system simplifications that were made would need to
be reverted because at build time we don't have a profile with
subdirs.el readily available, and must manually hunt for the guix.d
subdirectories.

3) Even if we scanned directories recursively for autoloads from
EMACSLOADPATH ourselves in emacs-guix.el, a user would still need to
call the guix-emacs-autoload-packages manually after installing new
Elisp packages to have Emacs find them.

I've tested these changes with a Gnome VM and the EMACSLOADPATH is now
reduced to just the Emacs' lisp directory as well as the
share/emacs/site-lisp directory of any profile.  Thanks for the great
ideas :-).

Some packages would need to be adapted to finalize the move to a
guix.d-less installation directory (some recipes refer to it), but this
is trivial to do.  The documentation would need to be adapted as well.
I can take care of this if someones deems the attached patches fit to
fix the problems mentioned in this ticket.

0001-build-emacs-build-system-Unify-the-installation-dire.patch
Description: Text Data

0002-gnu-emacs-Simplify-the-EMACSLOADPATH-search-path-spe.patch
Description: Text Data

0003-gnu-emacs-Fix-guix-emacs.el-indentation.patch
Description: Text Data

0004-gnu-emacs-Use-load-path-instead-of-EMACSLOADPATH.patch
Description: Text Data

0005-gnu-emacs-ert-runner-Fix-build.patch
Description: Text Data

0006-gnu-emacs-emacsql-Fix-build.patch
Description: Text Data

Maxim

vm-desktop-config.scm
Description: VM config for testing

signature.asc
Description: PGP signature