Installing gccEmacs (native-comp) with Nix

gccEmacs.md

WARNING: THIS GIST IS OUT OF DATE AND NO LONGER RELEVANT

• Native-comp was enabled by default in nixpgks
• Pgtk is not enabled by default, for that you can either override the derivation or use emacsPgtk from the nix-community emacs overlay if you don't want to build it yourself

Nix

Adding the overlay and configuring cachix

Option 1: Adding the overlay to configuration.nix or home.nix

Add the nix-community overlay to your nixpkgs. You can add the following to your configuration.nix (NixOS, non-user specific) or to your home-manager's home.nix. Note in the case of the latter, this will not be available for installation via nix-env.

{
  nixpkgs.overlays = [
    (import (builtins.fetchTarball {
      url = https://github.com/nix-community/emacs-overlay/archive/master.tar.gz;
    }))
  ];
}

See nixos or home-manager options for more information on adding overlays.

Option 2: Add to the overlays directory

echo "import (builtins.fetchTarball {
      url = https://github.com/nix-community/emacs-overlay/archive/master.tar.gz;
    })" >> $HOME/.config/nixpkgs/overlays/emacs.nix

Optional: Add cachix support to avoid compilation

As this package is installed via an overlay, it is not built by the Hydra CI/CD pipeline that underlies nixpkgs. Instead, the binary is built by the nix-community hydra and pushed to Cachix. Follow the instructions here to add the nix-community cachix.

nix-env -iA cachix -f https://cachix.org/api/v1/install
cachix use nix-community

You will need to ensure that you are are installing the emacs overlay from the nixos-unstable unstable channel, not the nixpkgs-unstable channel. If you are using home-manager, you will need to set your default channel to nixos-unstable (you can do this on non-NixOS systems, the difference is that nixos-unstable lags behind nixpkgs-unstable due to requiring more comprehensive tests before deployment). Alternatively, you can separately import nixos-unstable import <nixos-unstable> { overlays = [ overlay1 overlay2 ]; } separately, and use a separate channel specifically for emacs.

Installing emacs

If you followed option 2, the following will work.

nix-env -iA nixpkgs.emacsGcc

More likely, you will want to declaratively install in your configuration.nix or home.nix.

Home-manager provides a handy module, you can also add extra packages such as vterm.

{
  programs.emacs = {
    enable = true;
    package = pkgs.emacsGcc;
    extraPackages = (epkgs: [ epkgs.vterm ] );
  };
}

Alternatively you can add something like the following to you configuration.nix system packages

{
emacsWithPackages = (pkgs.emacsPackagesGen pkgs.emacsGcc).emacsWithPackages (epkgs: ([epkgs.vterm]));
}

Notes

As of 2020-08-03 the above works on fedora/ubuntu/debian and under NixOS. If you get an immediate segfault upon starting emacs, please ensure that your font is appropriately configured.

I really should take this gist down:

• Native-comp was enabled here
• Pgtk is not enabled by default, for that you can either override the derivation or use emacsPgtk from the emacs-overlay if you don't want to build it yourself

Thanks for the update ❤️ . Glad to hear about native-comp being enabled in the default builds.

I just tried adding a pgtk variant package (https://github.com/edrex/nixpkgs/tree/emacs-pgtk) but the result is running under xwayland, not sure what's up with that. Did I miss a flag (seems withGTK3 should default to true when withPgtk = true) or is it broken?

With this, there would be 4 variants (emacs with lucid, emacs-gtk with the old busted gtk/X hybrid, pgtk, and nox. Each of these does its own ELN/ELC precompilation steps, which take awhile (~30mins on my gen8 i7).

Is there anything we could do to share steps among the variants? Are the eln cache outputs the same with the different UI options? If so maybe we could split that into a shared package? That alone would help enormously, since the bulk of the build time is precompilation.

'Twere me, there would just be emacs with pgtk and nox, but I get that it would go against community norms to ship an unofficial patchset as the default. Any recent progress with pgtk upstream, or is it stuck?

I actually switched to helix awhile back, so I don't have too much of a horse in the game, but I still open up emacs to do my laundry ahem use magit.

The pgtk branch was merged awhile ago, I assume the reason that it's not the default in nixpkgs is because Xorg is still the default (for better or worse) and there is no reason to use pgtk on X11.

I don't use nix actively anymore, my understanding is that without content addressed derivations it would be difficult to share the compiled elisp since it's dependent on the emacs input (not sure about this). For your case, maybe consider a remote builder with hercules-ci or GHA.

Not a helix user (without plugins any editor is DOA for me)

no reason to use pgtk on X11

Oh right, that seems valid.

without content addressed derivations it would be difficult to share the compiled elisp

This also makes total sense, if the emacs build is used as an input to the compilation process. Ideally the emacs packages could be split into a minimal (nox) core that's used for compilation and then several gui layers, but IDT that would be easily doable.

without plugins any editor is DOA for me

I get that position. For me at least, the focus on working really well out of box is just.. so good and refreshing. They are taking their time adding features, and polishing and iterating each one carefully before moving on. Also, what people mean by "plugin" is quite variable, in terms of the capabilities provided by the plugin API. Some upcoming features (helix-editor/helix#3393, helix-editor/helix#4709) will satisfy a lot of the user-customization aspect of plugins, while a full plugin host is coming, just needs time to bake. Honestly, I've never been so productive in an editor, and it only took me about a week to become proficient, coming from vim/evil.

without content addressed derivations it would be difficult to share the compiled elisp

Actually hmm, I think we could just pick an emacs variant package to use for the compilation derivation, and have all variants depend on that same expression. Does that make sense?

I would suggest discussing this on matrix with the nix emacs people :)

will do. thanks for engaging :)