The first log in *Message* before this patch:
Loading /nix/store/bikm18vy6v07hmrvrll501i68440w9iw-emacs-29.1-rc1/share/emacs/site-lisp/site-start.el (source)...done
and after this patch:
Loading /nix/store/bikm18vy6v07hmrvrll501i68440w9iw-emacs-29.1-rc1/share/emacs/site-lisp/site-start (native compiled elisp)...done
I see no reason to symlink this dir.
Doing so may shadow unwanted libraries since the site-start.el of
Emacs adds paths under NIX_PROFILES to load-path.
It is added in [1] to fix "building emacs". However, I have no issue
in building and using Emacs after removing it.
[1]: https://github.com/NixOS/nixpkgs/pull/89351
"$out/share/emacs/site-lisp" is added to load-path in wrapper.sh[1]
using EMACSLOADPATH and "$out/share/emacs/native-lisp/" is added to
native-comp-eln-load-path in wrapper.sh[2] using
EMACSNATIVELOADPATH. There is no point to add them again here.
Additionally, the trailing "/" in "$out/share/emacs/native-lisp/"
causes duplicate entries in native-comp-eln-load-path:
("/nix/store/hash1-emacs-packages-deps/share/emacs/native-lisp/" ; [3]
"/home/user/.emacs.d/eln-cache/"
"/nix/store/hash1-emacs-packages-deps/share/emacs/native-lisp" ; [2]
"/nix/store/hash2-emacs-29.1-rc1/lib/emacs/29.1/native-lisp/")
load-path does not change with this patch applied.
[1]: 1476c13422/pkgs/build-support/emacs/wrapper.sh (L47)
[2]: 1476c13422/pkgs/build-support/emacs/wrapper.sh (L50)
[3]: 1476c13422/pkgs/build-support/emacs/wrapper.nix (L166)
The Nix-driven bootstrap of gcc resulted in some changes to the
structure of the `libgccjit` outpaths, and also added an additional
output (`libgcc`) to `gcc`.
This commit makes the corresponding changes in the `emacs`
derivation in order to not break emacs.
Emacs is the only user of `libgccjit` in nixpkgs at the moment.
This commit adds basic support for tree-sitter in the emacs build,
such that (if the user opts into tree-sitter support), tree-sitter
will be enabled and binary library files for tree-sitter can be
included in the `lib` directory of packages passed to
`emacsWithPackages`. The libraries will be aggregated and included in
treesit-extra-load-path.
The previous pattern for this in the community was to add tree-sitter
libaries by patching emacs's `RUNPATH` with `patchelf` in a post-fixup
phase. However, this has the substantial drawback that two different
emacs installations with different lists of available tree-sitter
libraries must be entirely separate builds. By supplying the
tree-sitter libraries in the wrapping layer of `emacsWithpackages`, it
becomes possible to share a single, more-cacheable "core emacs".
This support defaults to "on" only in emacs 29 and up, since previous
versions do not support tree-sitter out of the box.
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.
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")
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.
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.
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.
Among other things, this will allow *2nix tools to output plain data
while still being composable with the traditional
callPackage/.override interfaces.
In 8d76eff, @Ericson2314 changed the representation of the value that
`findInputs` generated from a whitespace-separated bunch strings to an
actual array of strings.
Expressions that *consume* that value, however, also needed to be
changed to iterate over all the contents of the array, else they would
only select the first value, which turns out to be somewhat limiting.
Fixes#27873
This reverts commit da68127737, reversing
changes made to 2ba494b728.
These changes are reverted because they cause an incompatibility which
they should not.
"emacsWrapper" replaces emacsWithPackages. In addition to "packagesFun",
emacsWrapper has an optional variable called "execStart". execStart can
be used to append elisp to the default site-start.el script. This is
useful for providing a way to load a user's .emacs.d/init.el
file. "emacsWithPackages" is implemented with emacsWrapper for
convenience and compatability.
Move all the dependencies to their own derivation, so that we don't publish all
of them if the wrapper is installed in a profile.
The previous solution just moved them to a custom directory to avoid conflicts,
this refactors that and completely hides them, while preserving the desired
improvement of adding only one directory to each of the emacs search paths
This is to avoid unwanted side effects when installing a wrapped emacs in the environment:
* All executables in the dependencies become available in the user environment
* All site-lisp binaries in the dependencies become accessible to unwrapped emacs
Also, both bin and site-lisp would generate conflicts so installing a wrapped emacs becomes really cumbersome
