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.
Create symlinks to the query files provided by the grammars. This
makes syntax highlighting works properly for languages which
tree-sitter-langs doesn't provide query files and updates the ones it
provides to the latest upstream files.
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.
* Add post-build script to generate autoloads file.
* Bump upstream revision to get a critical bugfix that prevented this library's
main function from executing.
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.
