mirrors/nixpkgs
1
0
Fork 1
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-12-25 03:17:13 +00:00
Code Issues Wiki Activity
nixpkgs/pkgs/applications/editors/emacs/build-support/wrapper.sh

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

57 lines
1.6 KiB
Bash
Raw Permalink Normal View History

emacsWithPackages: mutate EMACSLOADPATH correctly An empty entry in EMACSLOADPATH gets filled with the default value. This is presumably why the wrapper inserted a colon after the entry it added for the dependencies. But this naive approach wasn't always correct. For example, if the user ran emacs with EMACSLOADPATH=foo, the wrapper would insert the default value (by adding the trailing `:') even though the user was trying to expressly opt out of it. To do this correctly, here I've replaced makeWrapper with a bespoke script that will actually parse the EMACSLOADPATH provided in the environment (if given), and insert the wrapper's load path just before the default value. If EMACSLOADPATH is given but contains no default value, we respect that and don't add the wrapped dependencies at all. If no EMACSLOADPATH is given, we insert the wrapped dependencies before the default value, just like before. In this way, the wrapped Emacs should now behave as if the wrapped dependencies were part of Emacs's default load-path value.
2020-12-09 15:53:10 +00:00
#!@bash@
IFS=:
newLoadPath=()
emacs: Add comp-eln-load-path infrastructure
2020-11-16 19:24:29 +00:00
newNativeLoadPath=()
emacsWithPackages: fix logic of adding EMACSNATIVELOADPATH Without this change, EMACSNATIVELOADPATH will not be added if EMACSLOADPATH is added.
2023-08-25 03:30:25 +01:00
addedNewLoadPath=
addedNewNativeLoadPath=
emacsWithPackages: mutate EMACSLOADPATH correctly An empty entry in EMACSLOADPATH gets filled with the default value. This is presumably why the wrapper inserted a colon after the entry it added for the dependencies. But this naive approach wasn't always correct. For example, if the user ran emacs with EMACSLOADPATH=foo, the wrapper would insert the default value (by adding the trailing `:') even though the user was trying to expressly opt out of it. To do this correctly, here I've replaced makeWrapper with a bespoke script that will actually parse the EMACSLOADPATH provided in the environment (if given), and insert the wrapper's load path just before the default value. If EMACSLOADPATH is given but contains no default value, we respect that and don't add the wrapped dependencies at all. If no EMACSLOADPATH is given, we insert the wrapped dependencies before the default value, just like before. In this way, the wrapped Emacs should now behave as if the wrapped dependencies were part of Emacs's default load-path value.
2020-12-09 15:53:10 +00:00
if [[ -n $EMACSLOADPATH ]]
then
while read -rd: entry
do
emacsWithPackages: fix logic of adding EMACSNATIVELOADPATH Without this change, EMACSNATIVELOADPATH will not be added if EMACSLOADPATH is added.
2023-08-25 03:30:25 +01:00
if [[ -z $entry && -z $addedNewLoadPath ]]
emacsWithPackages: mutate EMACSLOADPATH correctly An empty entry in EMACSLOADPATH gets filled with the default value. This is presumably why the wrapper inserted a colon after the entry it added for the dependencies. But this naive approach wasn't always correct. For example, if the user ran emacs with EMACSLOADPATH=foo, the wrapper would insert the default value (by adding the trailing `:') even though the user was trying to expressly opt out of it. To do this correctly, here I've replaced makeWrapper with a bespoke script that will actually parse the EMACSLOADPATH provided in the environment (if given), and insert the wrapper's load path just before the default value. If EMACSLOADPATH is given but contains no default value, we respect that and don't add the wrapped dependencies at all. If no EMACSLOADPATH is given, we insert the wrapped dependencies before the default value, just like before. In this way, the wrapped Emacs should now behave as if the wrapped dependencies were part of Emacs's default load-path value.
2020-12-09 15:53:10 +00:00
then
newLoadPath+=(@wrapperSiteLisp@)
emacsWithPackages: fix logic of adding EMACSNATIVELOADPATH Without this change, EMACSNATIVELOADPATH will not be added if EMACSLOADPATH is added.
2023-08-25 03:30:25 +01:00
addedNewLoadPath=1
emacsWithPackages: mutate EMACSLOADPATH correctly An empty entry in EMACSLOADPATH gets filled with the default value. This is presumably why the wrapper inserted a colon after the entry it added for the dependencies. But this naive approach wasn't always correct. For example, if the user ran emacs with EMACSLOADPATH=foo, the wrapper would insert the default value (by adding the trailing `:') even though the user was trying to expressly opt out of it. To do this correctly, here I've replaced makeWrapper with a bespoke script that will actually parse the EMACSLOADPATH provided in the environment (if given), and insert the wrapper's load path just before the default value. If EMACSLOADPATH is given but contains no default value, we respect that and don't add the wrapped dependencies at all. If no EMACSLOADPATH is given, we insert the wrapped dependencies before the default value, just like before. In this way, the wrapped Emacs should now behave as if the wrapped dependencies were part of Emacs's default load-path value.
2020-12-09 15:53:10 +00:00
fi
newLoadPath+=("$entry")
done <<< "$EMACSLOADPATH:"
else
newLoadPath+=(@wrapperSiteLisp@)
newLoadPath+=("")
fi
emacsWithPackages: add a note for EMACSNATIVELOADPATH
2023-08-25 03:50:05 +01:00
# NOTE: Even though we treat EMACSNATIVELOADPATH like EMACSLOADPATH in
# this wrapper, empty elements in EMACSNATIVELOADPATH have no special
# meaning for Emacs. Only non-empty elements in EMACSNATIVELOADPATH
# will be prepended to native-comp-eln-load-path.
# https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/startup.el?id=3685387e609753293c4518be75e77c659c3b2d8d#n599
emacs: Add comp-eln-load-path infrastructure
2020-11-16 19:24:29 +00:00
if [[ -n $EMACSNATIVELOADPATH ]]
then
while read -rd: entry
do
emacsWithPackages: fix logic of adding EMACSNATIVELOADPATH Without this change, EMACSNATIVELOADPATH will not be added if EMACSLOADPATH is added.
2023-08-25 03:30:25 +01:00
if [[ -z $entry && -z $addedNewNativeLoadPath ]]
emacs: Add comp-eln-load-path infrastructure
2020-11-16 19:24:29 +00:00
then
newNativeLoadPath+=(@wrapperSiteLispNative@)
emacsWithPackages: fix logic of adding EMACSNATIVELOADPATH Without this change, EMACSNATIVELOADPATH will not be added if EMACSLOADPATH is added.
2023-08-25 03:30:25 +01:00
addedNewNativeLoadPath=1
emacs: Add comp-eln-load-path infrastructure
2020-11-16 19:24:29 +00:00
fi
newNativeLoadPath+=("$entry")
done <<< "$EMACSNATIVELOADPATH:"
else
newNativeLoadPath+=(@wrapperSiteLispNative@)
newNativeLoadPath+=("")
fi
emacsWithPackages: mutate EMACSLOADPATH correctly An empty entry in EMACSLOADPATH gets filled with the default value. This is presumably why the wrapper inserted a colon after the entry it added for the dependencies. But this naive approach wasn't always correct. For example, if the user ran emacs with EMACSLOADPATH=foo, the wrapper would insert the default value (by adding the trailing `:') even though the user was trying to expressly opt out of it. To do this correctly, here I've replaced makeWrapper with a bespoke script that will actually parse the EMACSLOADPATH provided in the environment (if given), and insert the wrapper's load path just before the default value. If EMACSLOADPATH is given but contains no default value, we respect that and don't add the wrapped dependencies at all. If no EMACSLOADPATH is given, we insert the wrapped dependencies before the default value, just like before. In this way, the wrapped Emacs should now behave as if the wrapped dependencies were part of Emacs's default load-path value.
2020-12-09 15:53:10 +00:00
export EMACSLOADPATH="${newLoadPath[*]}"
emacsWithPackages: don't tell sub-Emacs about pkgs If I'm running an Emacs executable from emacsWithPackages as my main programming environment, and I'm hacking on Emacs, or the Emacs packaging in Nixpkgs, or whatever, I don't want the Emacs packages from the wrapper to show up in the load path of that child Emacs. It results in differing behaviour depending on whether the child Emacs is run from Emacs or from, for example, an external terminal emulator, which is very surprising. To avoid this, pass another environment variable containing the wrapper site-lisp path, and use that value to remove the corresponding entry in EMACSLOADPATH, so it won't be propagated to child Emacsen.
2020-12-07 18:53:54 +00:00
export emacsWithPackages_siteLisp=@wrapperSiteLisp@
emacsWithPackages: mutate EMACSLOADPATH correctly An empty entry in EMACSLOADPATH gets filled with the default value. This is presumably why the wrapper inserted a colon after the entry it added for the dependencies. But this naive approach wasn't always correct. For example, if the user ran emacs with EMACSLOADPATH=foo, the wrapper would insert the default value (by adding the trailing `:') even though the user was trying to expressly opt out of it. To do this correctly, here I've replaced makeWrapper with a bespoke script that will actually parse the EMACSLOADPATH provided in the environment (if given), and insert the wrapper's load path just before the default value. If EMACSLOADPATH is given but contains no default value, we respect that and don't add the wrapped dependencies at all. If no EMACSLOADPATH is given, we insert the wrapped dependencies before the default value, just like before. In this way, the wrapped Emacs should now behave as if the wrapped dependencies were part of Emacs's default load-path value.
2020-12-09 15:53:10 +00:00
emacs: Add comp-eln-load-path infrastructure
2020-11-16 19:24:29 +00:00
export EMACSNATIVELOADPATH="${newNativeLoadPath[*]}"
export emacsWithPackages_siteLispNative=@wrapperSiteLispNative@
emacs: allow wrapped emacs to execute itself again fixes #145302 #237855 emacsWithPackages wrapper script/`site-start.el` sanitize EMACSLOADPATH, to make nested emacs invocations independent of the package set specified in emacsWithPackages. But there are valid use cases when one needs to call nested emacs with the same package set. This includes built-in emacs functionality such as async native compilations, and also external packages like `emacs-async` and `esup`. In all of these cases `invocation-directory`/`invocation-name` variables are being used to launch nested emacs. With this patch these variables will be populated to point to the emacsWithPackages wrapper executable, so that executing `(file-name-concat invocation-directory invocation-name)` will give a fully functional emacs again. `EMACSLOADPATH` sanitization was introduced by #106486, this behaviour stays unchanged. The reasoning was to be able to run different emacs executables without polluting their EMACSLOADPATH (as described here https://github.com/NixOS/nixpkgs/pull/106486/commits/23d4bfb6661ca57a9e331a2cf4184232d38ac38b). The only change is that invoking itself is again feasible (and that's what emacs actually expects). Co-authored-by: Lin Jian <me@linj.tech>
2024-12-02 16:04:15 +00:00
export emacsWithPackages_invocationDirectory=@wrapperInvocationDirectory@
export emacsWithPackages_invocationName=@wrapperInvocationName@
emacsWithPackages: Rely on package.el for autoloads The builtin `package.el` functionality is necessary and sufficient to handle autoloads in the Emacs wrapper.
2022-07-12 02:22:20 +01:00
exec @prog@ "$@"
Copy permalink