This will allow someone to ovewrite doom-emacs runtime environment
variables, e.g. DOOMDIR, so they can load a modified doom.d directory
for testing.
Fixes: #203
* Use `--init-directory` in Emacs 29+
This will allow a few advantages:
- We can load `early-init.el` file properly, fixing Flash Of Unstyled
Contents (FOUC) issues and improving the performance slightly
- Eventually we can drop `default.el` file loading in Home-Manager
module. Not done here since this would complicate the code without
necessity, however this can be done once Emacs 29+ is default
* Fix build in Emacs <29
* Add #checks.<arch>.init-example-el-emacsGit
* Add .#checks.x86_64-linux.init-example-el-emacsGit to CI
* Fix review issues
* Move config files to share/emacs.d
* Separate tests in two steps
* Add TODOS
* Simplify emacs-dir generation
Before this change, trying to use `doom/restart-and-restore` would
result in a failed to load `default.el` as the wrong binary would be launched.
This fixes that.
If input name contains `.` character then `invalid flake input path
element` error message is displayed on running `nix flake update
--update-input x.y`
Additional refactors made:
* eliminated the quirky $out/bin/$(basename $prog) path calculation as
it equals to $prog anyway (I have no idea why was it that way...)
* Removed the platform dependent optionalString call as there is an
additional runtime check anyway for the existence of Applications
directory.
Referecnes: #100
If built with gccEmacs, in `straight--native-compile-package` step tries
to access $HOME because `comp-eln-load-path` contains
"~/.emacs.d/eln-cache/". It errors on this as it is set to a readonly canary value of
`/homeless-shellter` in the nix build sandbox.
The workaround is twofold:
* Ignore `kill-emacs` from optimization. It would result in eln file
being written before doom sets up the load path outside of HOME.
* The above solution doesn't help in the actual build phase because the
worker processes compiling packages does not inherit this value but
it is set in them at a later time. This causes the build to fail
before `comp-eln-load-path` would be successfully overridden. Having
a writable $HOME does not seem to produce any build output there
hence the override and the check in `postInstall` to verify that the
directory is indeed empty.
The runtime value of `comp-eln-load-path` also had to be changed because
it is by default is located under the volatile `doom-cache-dir` which is
not a part of the derivation so the build time generated `.eln` files
couldn't be loaded from that.
References: #57
This is needed as custom packages may need the same treatment as
built-in dependencies of doom. See `./overrides.nix` for details.
The `bundledPackages` option may be consolidated to use this argument as
well in the future.
References: #55
