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
