emacs: 27.2 -> 28.1

[azahi]

Description of changes

https://github.com/emacs-mirror/emacs/blob/emacs-28.1/etc/NEWS
https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00093.html

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[azahi]

I took a liberty enabling nativecomp by default and deleting (possibly) an unused patch file.

I did not build and test all of the 44 packages that depend on the emacs package. I also didn't manage to make emacs-daemon test to succeed: it errors out with something like this

vm-test-run-emacs-daemon> (finished: waiting for success: systemctl --user status emacs.service | grep 'Active: active', in 3.30 seconds)
vm-test-run-emacs-daemon> machine: must succeed: emacsclient --create-frame $EDITOR >&2 &
vm-test-run-emacs-daemon> (finished: must succeed: emacsclient --create-frame $EDITOR >&2 &, in 0.02 seconds)
vm-test-run-emacs-daemon> machine: waiting for emacseditor to appear on screen
vm-test-run-emacs-daemon> machine: sending monitor command: screendump /build/tmp9p0v4guu/ppm
vm-test-run-emacs-daemon> machine: waiting for monitor prompt
vm-test-run-emacs-daemon> (finished: waiting for monitor prompt, in 0.00 seconds)
vm-test-run-emacs-daemon> (finished: sending monitor command: screendump /build/tmp9p0v4guu/ppm, in 0.00 seconds)
vm-test-run-emacs-daemon> machine # Waiting for Emacs...
vm-test-run-emacs-daemon> machine # *ERROR*: Unknown terminal type

and then just cycles infinitely. Executing the binary and doing some trivial tasks works just fine.

Any help would be appreciated.

[wahjava]

Thanks for working on the update.

I took a liberty enabling nativecomp by default and deleting (possibly) an unused patch file.

IMHO, nativecomp should not be enabled by default. It takes a long time to build itself, and then it uses 100% CPU (in its default configuration) when you install any new packages for native compilation. I've used it for sometime, and other than increasing the temperature of the CPU, I didn't feel much difference in the performance, and so I ended up reverting back to without nativecomp.

[siraben]

nativecomp can be disabled by setting no-native-compile or no-byte-compile to non-nil.

I think that creating another definition for Emacs with native compilation (similar to emacs-overlay) would be a good idea, leaving native compilation disabled for the emacs derivation.

[azahi]

I think that creating another definition for Emacs with native compilation (similar to emacs-overlay) would be a good idea, leaving native compilation disabled for the emacs derivation.

That sounds reasonable. I will make changes later today.

[azahi]

@wahjava @siraben I've added an additional derivation and called it emacs28NativeComp.

[jwiegley]

I'll give this a try today.

[azahi]

@azahi When I try to build this on macOS Big Sur, I get: install: cannot stat 'org.elc': No such file or directory

Unfortunately, I have no way of testing and debugging the build on MacOS. I don't think that I can help you with that.

[jwiegley]

@azahi I figured out the problem. Everything seems to be looking good on my side, I'll switch to using this version for the next few days and will let you know if I run into any problems. Thank you for the work!

[wahjava]

I switched to emacs28, and everything seems to work okay.

Thank you!

[wineee]

Can we add the emacsPgtk derivation， which support Wayland natively, (like emacs-overlay)

[azahi]

Can we add the emacsPgtk branch， which support Wayland natively, (like emacs-overlay)

This is probably goes out of scope of this PR given that pGTK was not released as part of 28.1. You can check out the release notes[1], there is no mention of pGTK support there. It is promised to be included in the 29.1 version IIRC. [1] https://github.com/emacs-mirror/emacs/blob/emacs-28/etc/NEWS

[axelf4]

I also didn't manage to make emacs-daemon test to succeed: it errors out with something like this

[...]
vm-test-run-emacs-daemon> machine # Waiting for Emacs...
vm-test-run-emacs-daemon> machine # *ERROR*: Unknown terminal type

and then just cycles infinitely.

I took a look at this, and from what I gather explicitly setting the display frame parameter makes make-frame not try to make sense of the dumb TTY type when no GUI frames exist yet. That is, this patch makes the test succeed:

diff --git a/nixos/tests/emacs-daemon.nix b/nixos/tests/emacs-daemon.nix
index d53031a67f6..310e93e19b0 100644
--- a/nixos/tests/emacs-daemon.nix
+++ b/nixos/tests/emacs-daemon.nix
@@ -33,7 +33,7 @@ import ./make-test-python.nix ({ pkgs, ...} : {
       )
 
       # connects to the daemon
-      machine.succeed("emacsclient --create-frame $EDITOR >&2 &")
+      machine.succeed("emacsclient --no-wait --frame-parameters='((display . \"'\"$DISPLAY\"'\"))' --create-frame $EDITOR >&2")
 
       # checks that Emacs shows the edited filename
       machine.wait_for_text("emacseditor")

I have to say, I do not fully understand what actually caused the test to start failing, but it is safe to say that it is an upstream issue based on the workaround.

[jwiegley]

All has been working well for me.

[azahi]

@axelf4 Thanks. I've pushed an additional commit with your patch. The test is working fine now.

[adisbladis]

I'm actually wondering if there is much point in not enabling native compilation outright?
It has quite significant speedups and hasn't broken all that much in a very long time for us in the emacs overlay.

[siraben]

@adisbladis probably concerns about increased CPU usage since it compiles everything and can drain the battery on laptop devices.

[axelf4]

probably concerns about increased CPU usage since it compiles everything and can drain the battery on laptop devices.

Would not those users be better off disabling just-in-time native compilation in their init files, while still benefiting from the packaged Emacs distribution being ahead-of-time compiled?

[azahi]

I went on Repology and looked up how other distributions package 28.1:

• Additional nativecomp package:

  • Arch Linux
  • Parabola

• nativecomp not enabled:

  • Alpine Linux
  • Solus
  • Gentoo (USE flag is disabled by default)
  • FreeBSD (Look for NATIVECOMP=off)

I'm still a bit uncertain over that if we should enable it by default or not. I think having a separate package could be the safest bet for the time being.

[adisbladis]

Would not those users be better off disabling just-in-time native compilation in their init files, while still benefiting from the packaged Emacs distribution being ahead-of-time compiled?

@axelf4 I think that's what we'll eventually end up doing, but for now the additional attribute is fine and risk-free.
We could revisit this soon after the 22.05 branch-off or in a follow-up PR and quickly relegate the emacsNativeComp attribute to an alias.

[jian-lin]

A follow-up PR #176780 to enable native-comp by default.

Reviews are welcome.