A list of modifications:
- The calling handles at `top-level/all-packages.nix` were transferred to
`pkgs/applications/editors/emacs/default.nix` (the good old `recurseIntoAttrs`
design pattern);
- The files `macport.nix` and `28.nix` were removed, replaced by the bigger and
better `sources.nix`;
- Aliases for the most important derivations were put on `all-packages.nix`;
- The file `generic.nix` was refactored. Among its changes, the most noticeable:
- `pname` is decorated according to the selected UI options;
- Environment variables are explicitly under `env` set;
- The `null` defaults and (in)equality tests were removed;
- It obliged the addition of some Boolean flag guards;
- The flag `noGui` was added, allowing easier override for `emacs-nox`.
With this huge refactor, the emacs build functions become more sane and
maintainable, allowing future additions.
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.
Many packages have some kind of flag indicating whether or not to build with
systemd support. Most of these default to `stdenv.isLinux`, but systemd does
not build on (and is marked `broken` for) `isStatic`. Only a few packages have
the needed `&& !isStatic` in the default value for their parameter.
This commit moves the logic for the default value of these flags into
`systemd.meta.{platforms,badPlatforms}` and evaluates those conditions using
`lib.meta.availableOn`.
This provides three benefits:
1. The default values are set correctly (i.e. including `&& isStatic`)
2. The default values are set consistently
3. The way is paved for any future non-Linux systemd platforms (FreeBSD is
reported to have experimental systemd support)
Emacs built with pgtk ("pure gtk") isn't X, so `withX` isn't true.
This commit extends the test conditions for format libraries inclusion
to withX || withPgtk, so Pgtk Emacs gets image format support
libraries as well.
Co-authored-by: Atemu <atemu.main@gmail.com>
Because of long standing bugs and stability issues & an
uncollaborative upstream there has been talk on the emacs-devel
mailing list to switch the default toolkit to
Lucid (https://lists.gnu.org/archive/html/emacs-devel/2022-08/msg00752.html).
The GTK build also has issues with Xinput2, something that both we and
upstream want to enable by default in Emacs 29.
This situation has prompted me to use both Lucid an no-toolkit (pure X11) Emacs
as a daily driver in recent weeks to evaluate what the
advantages/drawbacks are and I have concluded that, at least for me,
switching the toolkit to Lucid is strictly an upgrade.
It has resulted in better stability (there are far fewer tiny UX
issues that are hard to understand/identify) & a snappier UI.
On top of that the closure size is reduced by ~10%.
In the pure X11 build I noticed some unsharpness around fonts so this
is not a good default choice.
As with everything there is a cost, and that is uglier (I think most
would agree but of course this is subjective) menu bars for
those that use them and no GTK scroll bars.
For anyone who still wants to use GTK they could of course still
choose to do so via the new `emacs-gtk` attribute but I think this
is a bad default.
A note to Wayland users:
This does not affect Wayland compatibility in any way since that will
already need a PGTK build variant in the future.
In the past the motivation to not recurse into Emacs packages was that
it added quite a lot of packages to the evalution and they were so
fast to build locally that substituting them from a binary cache
didn't make sense.
With native compilation this equation has changed drastically, build
times are much longer and build closures are larger so the utility
of having cached packages has gone way up.
Additionally, it looks to me like Emacs is the only ecosystem in nixpkgs to
ever care about evaluation performance like this.
Every other extensible editor ecosystem has recurseIntoAttrs set to true on their respective
package sets.
Quoting @collares from #170426:
> The difference between the two versions is that one is built from the
> tarball, while the other is built from Git. The tarball includes
> byte-compiled (.elc) files but not native-compiled (.eln)
> files. The build notices the .elc files and does not rebuild them,
> but native-compilation is a side-effect of byte-compilation and so
> the .eln files aren't built either.