The vscodium project is now releasing artifacts with slightly different naming: `VSCodium-darwin-${VSCODIUM_VER}.zip` is now `VSCodium-darwin-x64-${VSCODIUM_VER}.zip`. This is likely due to arrival of the new ARM-based macs. In any case, it does mean that we need to update `update-vscodium.sh` to pull the correct artifact down.
Files generated by emacs2nix will now end in a final newline, as is
now required by the Nixpkgs editorconfig-checker CI action.
See <https://github.com/ttuegel/emacs2nix/pull/51>.
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.
siteVersionDir isn't a full path, it's just the name of the version
directory entry in $out/share/emacs, e.g. "27.1", so since
d1b0eef9b5 ("emacs: Don't use interpolation for version"), we've been
trying to remove a non-existent directory. This would have been
caught if we hadn't been giving -f to rm unnecessarily, because -f
suppresses errors. As well as fixing the path, I've removed the -f
from rm. Doing this to the line above as well revealed that rm-ing
$out/var was no longer necessary, since nothing has been put there
since ac23a7c459 ("emacs: 25.3 → 26.1") -- it would now only be
created if we set the --with-gameuser configure option, which we
don't.
