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

From: Leo Prikler <[email-masked]>
Date: Wed, 27 Nov 2019 01:01:31 +0100

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.

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.

WDYT?

Regards,
Leo

[1] As I only vaguely remember it, I can not find a source for this. 
However, the process that I've laid out should work fine with or
without guix.d