-
Update: related issue filed at #318 I'm not really sure what's going on here since I didn't change this piece. I use emacs overlay like this:
It is tracked by the way:
It's not taking effect any more and seems to not apply to any
I think a while ago when I worked with @nrdxp over discord we had a similar issue where the order of overlays mattered for the emacs overlay. So based on that hunch I'm about to try this in digga.lib.mkFlake {
inherit self inputs;
channelsConfig = { allowUnfree = true; };
channels = {
nixos = {
imports = [ (digga.lib.importers.overlays ./overlays) ];
overlays = [
./pkgs/default.nix
+ emacs-overlay.overlay
pkgs.overlay # for `srcs`
nur.overlay
agenix.overlay
- emacs-overlay.overlay
];
};
latest = { };
}; I have no idea if this will work, but the rationale is that maybe the pkg overlays have to happen after the emacs overlay is loaded. Also, here is how I'm testing:
Edit: Here is some extra context that could help:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Indeed the order of overlays matter. I strongly hypothesize that the raked overlays are applied first (via the module list merging mechanism). This is an awkward behaviour since the raked overlays are usually meant to be applied post-external overlays. I think this is in merit of a propper issue. I remeber having stumbled over such thing, previously. |
Beta Was this translation helpful? Give feedback.
Indeed the order of overlays matter. I strongly hypothesize that the raked overlays are applied first (via the module list merging mechanism).
This is an awkward behaviour since the raked overlays are usually meant to be applied post-external overlays.
I think this is in merit of a propper issue.
I remeber having stumbled over such thing, previously.