GNU bug report logs -
#38309
Recent $EMACSLOADPATH changes crash gnome-session
Previous Next
Reported by: "Alex Griffin" <a <at> ajgrf.com>
Date: Thu, 21 Nov 2019 02:27:01 UTC
Severity: serious
Done: clement <at> lassieur.org (Clément Lassieur)
Bug is archived. No further changes may be made.
Full log
Message #61 received at 38309 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Leo!
Leo Prikler <leo.prikler <at> student.tugraz.at> 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 (text/x-patch, attachment)]
[0002-gnu-emacs-Simplify-the-EMACSLOADPATH-search-path-spe.patch (text/x-patch, attachment)]
[0003-gnu-emacs-Fix-guix-emacs.el-indentation.patch (text/x-patch, attachment)]
[0004-gnu-emacs-Use-load-path-instead-of-EMACSLOADPATH.patch (text/x-patch, attachment)]
[0005-gnu-emacs-ert-runner-Fix-build.patch (text/x-patch, attachment)]
[0006-gnu-emacs-emacsql-Fix-build.patch (text/x-patch, attachment)]
[Message part 8 (text/plain, inline)]
Maxim
[vm-desktop-config.scm (text/plain, attachment)]
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 5 years and 167 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.