bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr

[Eli Zaretskii]

> From: Jonas Bernoulli <jonas@bernoul.li>
> Cc: 58073@debbugs.gnu.org
> Date: Sun, 25 Sep 2022 20:30:05 +0200
> 
> Installing emacs using guix sets EMACSLOADPATH in a file that is sourced
> by the shells startup file.  To me it looks like they are abusing this
> variable; it makes it impossible to use an emacs that wasn't installed
> using guix, without something to counter their modification.  I did that
> with a wrapper script.
> 
> The value that is set somewhere in the shell's init files is something
> like "/home/jonas/.guix-home/profile/share/emacs/site-lisp".  It doesn't
> contain an empty element, which would "stand for the default value of
> `load-path'", according to (info "(emacs)General Variables").
> 
> The side startup file is located inside this directory and contains
> 
>   (when (require 'guix-emacs nil t)
>     (guix-emacs-autoload-packages)
>     (advice-add 'package-load-all-descriptors :after
>                 #'guix-emacs-load-package-descriptors))
> 
> The file "guix-emacs.el" is located in the same directory.  So the
> purpose of setting EMACSLOADPATH seems to be to allow using `require' to
> load that file.  This doesn't seem right to me, they could just as well
> extend the load-path inside "site-lisp.el", or load their additional
> init file using `load'.
> 
> To deal with the incomplete EMACSLOADPATH, as set in the shell
> environment, they use a wrapper script named "emacs" and located on PATH:
> 
>   #!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash
>   export 
> XDG_DATA_DIRS="/gnu/store/h6qdfd4sjdg28jq16600hcjky0cfw9gx-shared-mime-info-1.15/share:/gnu/store/bnsf9il448hl5xjavbhq3rcx355svz2v-glib-2.70.2/share:/gnu/store/7njbpmsgwmx59xn2r6q097iy2wwscb44-gtk+-3.24.30/share:/gnu/store/w0ssipd06il3kvyvqihpmw4lwbhwwfq3-emacs-28.1/share${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS"
>   export 
> GTK_PATH="/gnu/store/7njbpmsgwmx59xn2r6q097iy2wwscb44-gtk+-3.24.30/lib/gtk-3.0${GTK_PATH:+:}$GTK_PATH"
>   export 
> PATH="$PATH${PATH:+:}/gnu/store/0c1yfbxyv877mlgychfgvmk5ha2jqh52-gzip-1.10/bin:/gnu/store/8fpk2cja3f07xls48jfnpgrzrljpqivr-coreutils-8.32/bin"
>   export 
> EMACSLOADPATH="$EMACSLOADPATH${EMACSLOADPATH:+:}/gnu/store/w0ssipd06il3kvyvqihpmw4lwbhwwfq3-emacs-28.1/share/emacs/28.1/lisp"
>   exec -a "$0" 
> "/gnu/store/w0ssipd06il3kvyvqihpmw4lwbhwwfq3-emacs-28.1/bin/.emacs-28.1-real" 
> "$@"
> 
> I am under the impression that they should stop setting EMACSLOADPATH
> and should either invent their own variable to replace that or load
> "guix-emacs.el" using simpler means as I suggested above.

I tend to agree.  I don't understand why they "invade" EMACSLOADPATH:
that is supposed to be left to the users.

> > Emacs has special support for running from the build tree, but in your
> > case it somehow doesn't realize that.
> 
> As a side-note, the wrapper script that I previously used looked like
> this:
> 
>   #!/bin/sh
>   export EMACSLOADPATH="\
>   /home/jonas/.guix-home/profile/share/emacs/site-lisp:\
>   /home/jonas/src/emacs/emacs/lisp"
>   exec -a "$0" "/home/jonas/src/emacs/emacs/src/emacs" "$@"
> 
> The build tree is at "/home/jonas/src/emacs/emacs"; I think the value I
> set above is correct (correct me if I am wrong), so it seems that when
> running from the build tree EMACSLOADPATH has to be unset; explicitly
> doubling down on the defaults doesn't work.  I also tried with an empty
> element.

Your EMACSLOADPATH is not entirely correct, I think: it doesn't
include the subdirectories of /home/jonas/src/emacs/emacs/lisp.

All in all, when you run Emacs either from the source tree, or from
the place where it was configured to be installed, there should be no
need to set EMACSLOADPATH, and doing so without being VERY careful
could indeed get you in trouble.