This commits changes the Emacs wrapper, in order to preload all autoload
definitions when built with additional packages. The list of all
definitions is generated at build-time. Packages do not need to
be (require)d for them to work.
Before this change, a code like
```sh
nix-shell -I "nixpkgs=$PWD" -p "emacs.pkgs.withPackages(e:[e.magit])" \
--run "emacs -Q -nw -f magit"
```
will fail with the message `Symbol’s function definition is void: magit`
After the change, the same code above will open Emacs with magit
enabled.
A slightly longer startup time of ~10ms was detected in local, informal
experiments.
More information on autoloading:
https://www.gnu.org/software/emacs/manual/html_node/eintr/Autoload.html
Since the included package set is determined at build time we can also
generate the `subdirs.el` file at build time. This improves startup
time somewhat since we don't have to traverse the directory to add to
`load-path`.
For example,
``` sh-session
$ bench './emacs-old -Q --batch --kill' './emacs-new -Q --batch --kill'
benchmarking bench/./emacs-old -Q --batch --kill
time 72.77 ms (71.66 ms .. 73.65 ms)
1.000 R² (0.999 R² .. 1.000 R²)
mean 72.49 ms (72.06 ms .. 72.92 ms)
std dev 746.5 μs (582.4 μs .. 1.008 ms)
benchmarking bench/./emacs-new -Q --batch --kill
time 40.56 ms (40.24 ms .. 40.86 ms)
1.000 R² (0.999 R² .. 1.000 R²)
mean 40.30 ms (40.12 ms .. 40.51 ms)
std dev 401.9 μs (311.1 μs .. 555.8 μs)
```
The change does not actually affect the content of `load-path`:
``` sh-session
$ diff -s <(./emacs-old --batch --eval '(prin1 load-path)' | sed -E 's!/nix/store/[[:alnum:]]{32}-!!g') \
<(./emacs-new --batch --eval '(prin1 load-path)' | sed -E 's!/nix/store/[[:alnum:]]{32}-!!g')
Files /dev/fd/63 and /dev/fd/62 are identical
```
So in principle the only observable effect should be the improved
startup time.
I think this is due an update. I've chosen to update to the latest
version that has been merged into Melpa.
Unfortunately we now need to hack around it trying to run VCS
commands.
My Emacs configuration with thirty-something leaf packages seems fine
after the rebuild.
This change allows ELPA packages to have their src attribute updated
by overrideAttrs. Without this change the installPhase references the
original src attribute and overriding is not possible.
This change makes the wrapper script avoid displaying echo area messages
during startup. This helps prevent split second UI glitches early in the
startup process. The messages itself will still be logged and therefore
will not hamper inspection for debugging purposes.
This was already fixed on non-Darwin, but the fix missed that it was
also reintroduced for the Darwin code path at the same time.
Fixes: dd5d2482c9 ("emacs: Fix accidental double wrapping")
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.
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.
Previously, meta wasn't being passed through at all, because it's
removed from args without being used anywhere. This made it so that
rcirc-menu wasn't being marked as broken even though it was supposed
to be.
This patch copies the meta handling from melpaBuild, including the
default home page (adapted for ELPA).
- Add packages installed in a sub-directory of site-lisp, such as
mu4e, to EMACSLOADPATH.
- Add ELPA packages to EMACSLOADPATH.
- Add each package only once to EMACSLOADPATH. Before, each package
would typically be added twice for each transitive dependency
leading to a huge variable for a package having many dependencies.
Fixed#78680
This removes the unnecessary compiler build dependency. We also set
preferLocalBuild = true;
allowSubstitutes = false;
to not farm out the build on a remote builder or bother with trying to
find a binary substitution.
Emacs loads all the elisp files in the top-level of the site-lisp
directory. However some packages (e.g. mu4e) put their elisp files in a
subdirectory of site-lisp. Emacs will not load these packages unless
subdirs.el is present.
This commit links the subdirs.el file from the emacs package into the
emacs-package-deps package so that packages that put their elisp files
in a subdirectory of site-lisp are loaded.
This commit causes melpaBuild to use package-build from melpa/package-build
instead of melpa/melpa. Development of package-build happens in the former
repository whereas the latter is much larger, containing also the MELPA
recipes. We do not need to fetch the MELPA recipes from melpa/melpa, as we fetch
them one-by-one for Nixpkgs.
No real function change here, but this updates the trivial and melpa builders to
be formatted more consistently with the rest of the builders, and swaps
`eval "$preBuild"` for the more standard `runHook preBuild`.
The `overrideScope` bound by `makeScope` (via special `callPackage`)
took an override in the form `super: self { … }`. But this is
dangerously close to the `self: super { … }` form used by *everything*
else, even other definitions of `overrideScope`! Since that
implementation did not even share any code either until I changed it
recently in 3cf43547f4, this inconsistency
is almost certainly an oversight and not intentional.
Unfortunately, just as the inconstency is hard to debug if one just
assumes the conventional order, any sudden fix would break existing
overrides in the same hard-to-debug way. So instead of changing the
definition a new `overrideScope'` with the conventional order is added,
and old `overrideScope` deprecated with a warning saying to use
`overrideScope'` instead. That will hopefully get people to stop using
`overrideScope`, freeing our hand to change or remove it in the future.
