Provide tangled .el file from Org configs

[jhenahan]

While striving for an ever more turnkey system deployment, I ran into the issue of "how do I tell Emacs to tangle my Org config whenever I change it when Nix sets mtime to epoch 0?". I settled on a home-manager activation script to symlink my Org file into ~/.emacs.d for now, but I thought it'd be cool to expose an attribute or something off of an emacsWithPackagesFromUsePackage (or maybe just a totally separate function, I dunno) to hold the tangled config for direct symlinking (maybe even byte compile it if there's a sane way to do that).

I'm probably gonna play around and see if I can cobble something together out of fromElisp, so this is more of an interest check and a call for anyone who's been down this road before to spill their secrets or tell me that this is a terrible idea. :D

[terlar]

If you want some inspiration I do this in my config: https://github.com/terlar/emacs-config/blob/master/default.nix#L11-L27

1. I tangle the org file which results in a init.el and a early-init.el.
2. I also generate package-quickstart.
3. Then everything is byte-compiled via the derivation trivialBuild.

[adisbladis]

I would like to take this even further and embed the config in the Emacs closure regardless of tangling. I'd be very happy if someone made a PR for that.

[lambdadog]

@adisbladis Unfortunately this is a somewhat complex problem with emacs. I've gone through several iterations of my emacsWithConfig function and pored through lisp/startup.el plenty and it doesn't paint a great picture.

This is the list of options I've found:

• XDG_CONFIG_HOME
  • + Allows setting both init and early-init
  • - Is searched for after ~/.emacs and ~/.emacs.d/, so you need to ensure they don't exist in order for your config to be loaded
  • - Only supported by emacs >= 27.1
  • - Causes some issues with variables initialized using locate-user-emacs-file or user-emacs-directory for substitution prior to resetting user-emacs-directory, since emacs is initialized with a user-emacs-directory that's not writeable.
    • I've only bumped into this a couple of times, since I set user-emacs-directory to ~/.local/share/emacs in early-init.el before loading the nix autoloads, but it's something that can still bite you and require workarounds with packages that are included in emacs.
  • This is what I currently do, with a wrapper that fails early if .emacs.d or .emacs exist
• default package
  • + Can just be used directly with emacsWithPackages
  • - Loads after an existing init file, if it exists
  • - Requires specifying your init differently from the standard (in the form of a package named default)
    • Could be wrapped well enough to allow you to set your config in a more normal way, though
  • - Cannot set early-init
• site-start package
  • + Can just be used directly with emacsWithPackages
  • + Can inhibit init file loading (I believe, I haven't tested this)
  • - Requires specifying your init differently from the standard (in the form of a package named site-start)
    • Could be wrapped well enough to allow you to set your config in a more normal way, though
  • - Is already used by nixpkgs, behavior would need to be replicated
  • - Still loads after early-init if early-init is found
• emacs -q --load <initFile>
  • + Resilient to any state of the user directory
  • + Theming loads prior to emacs opening, avoiding the unpleasant "emacs flash"
    • This is just a nice bonus, but I appreciate it
  • - Breaks some packages
    • dashboard, as an example, which is dependent on the number of args passed to emacs to show the dashboard
    • I'm wary of the effects this may have on anything that starts up emacs subprocesses (async elisp, etc)
  • I used to do this, prior to emacs 27.1

[lambdadog]

There's also the option of setting HOME prior to loading emacs but IMO that's a very unhappy solution since a lot of things would be set using the HOME variable during load that would need to be reset, even more than user-emacs-directory with XDG_CONFIG_HOME.

Anything further would require patching emacs, which I admit I've considered once or twice, but I don't think would tell a happy story about integrating software with nix. It might be an undertaking I consider at some point down the line though regardless.