[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr
From: |
Jonas Bernoulli |
Subject: |
bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr |
Date: |
Sun, 02 Oct 2022 16:50:19 +0200 |
Eli Zaretskii <eliz@gnu.org> writes:
>> 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.
It probably will be a while until I submit a patch for Guix (am very
new to the distro). Meanwhile I'll keep using a wrapper script. In
case someone else runs into the same problem until I get around to it,
here is what I currently use:
#!/bin/sh
unset EMACSLOADPATH
exec -a "emacs" "/home/jonas/src/emacs/emacs/src/emacs" "$@"
One problem with that approach is that the wrapper cannot be named
"emacs". If it is named "emacs", then that somehow trips up Emacs
and it loads all the preloaded files explicitly during startup (so
it appears that it cannot find the pdumper file in this case).
Eli, this isn't terribly important, but I was wondering if there is
something you could do so the name of the wrapper does not matter?
There might be other legitimate uses of a wrapper around the binary
from the build directory, other than "I currently have not other
choice because of what my distro does".
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr,
Jonas Bernoulli <=
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Eli Zaretskii, 2022/10/02
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Jonas Bernoulli, 2022/10/02
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Stefan Kangas, 2022/10/02
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Eli Zaretskii, 2022/10/02
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Jonas Bernoulli, 2022/10/03
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Eli Zaretskii, 2022/10/03
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Jonas Bernoulli, 2022/10/03
- bug#58073: 29.0.50; Uninstalled emacs sends startup messages to stderr, Eli Zaretskii, 2022/10/03