Hello Leo! Leo Prikler 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.