!SlMumQZnFjwLRjWFbW:nixos.org

Nix + Doom Emacs

201 Members
Running Doom Emacs with Nix | You probably want https://github.com/nix-community/nix-doom-emacs42 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
14 Oct 2022
@sg-qwt:nltrix.net@sg-qwt:nltrix.net I'm fairly new to doom (coming from spacemacs :D), my doom config is grabbed fresh from https://github.com/doomemacs/doomemacs/tree/master/templates, so I guess that's not relevant. I guess this error is related to NativeComp? However, when I nixos-rebuild and switch, everything seems build fine and no errors pop up. 16:33:51
@hab25:matrix.org@hab25:matrix.org
In reply to @sg-qwt:nltrix.net

hi folks, I've got a pretty basic fresh setup from master nix-doom-emacs and master emacs-overlay like below, nothing fancy

programs.doom-emacs =  {
        enable = true;
        doomPrivateDir = ../config/doom-emacs;
        emacsPackage = pkgs.emacsPgtkNativeComp; 
     }

on fresh doom emacs start, I've got Error (doom-init-ui-hook): Error running hook "+doom-dashboard-init-h" because: (void-function doom-modeline-set-project-modeline) , I also noticed magit status does not startup due to similar error function is void: doom-modeline-set-vcs-modeline

does anyone encounter same issue here or know how to fix this?

I encountered both issues. My workaround was to disable the dashboard and modeline doom modules in init.el.
20:23:31
@sg-qwt:nltrix.net@sg-qwt:nltrix.net
In reply to @hab25:matrix.org
I encountered both issues. My workaround was to disable the dashboard and modeline doom modules in init.el.

haha..that's what i currently done..

on a deep thought though, there's logic error for my current flake dependency layout:

    emacs = {
      url = "github:nix-community/emacs-overlay";
      inputs.nixpkgs.follows = "nixpkgs";
    };
    
    nix-doom-emacs = {
      url = "github:nix-community/nix-doom-emacs";
      inputs.nixpkgs.follows = "nixpkgs";
      inputs.emacs-overlay.follows = "emacs";
    };

ideally, emacs would follow nix-doom-emacs.inputs.emacs-overlay, not the other way around, not sure if that's causing the problem though..

20:26:34
@hab25:matrix.org@hab25:matrix.org

I'm not using emacs-overlay at all; I don't think it's related to that.

PS: Though it seems that most flakes-supporting projects recommend it, I think using follows is a bad idea, unless you are willing to sacrifice stability for faster builds. The reason is, when you do this you are overriding the pins that the developers tested with. Big disclaimer: I'm new to flakes.

20:37:26
@sg-qwt:nltrix.net@sg-qwt:nltrix.net

in order to pin emacs-overlay exactly same as nix-doom-emacs, I ended-up with a single nix-doom-emacs flake input and used overlay like below

    nix-doom-emacs = {
      url = "github:nix-community/nix-doom-emacs";
      inputs.nixpkgs.follows = "nixpkgs";
    };
     overlays = [
          (import nix-doom-emacs.inputs.emacs-overlay.outPath)
     ];

but problem still exists, so I guess as hab25 said, that's something else then..

20:46:40
@sg-qwt:nltrix.net@sg-qwt:nltrix.net *

in order to pin emacs-overlay exactly same as nix-doom-emacs's input, I ended-up with a single nix-doom-emacs flake input and used overlay like below

    nix-doom-emacs = {
      url = "github:nix-community/nix-doom-emacs";
      inputs.nixpkgs.follows = "nixpkgs";
    };
     overlays = [
          (import nix-doom-emacs.inputs.emacs-overlay.outPath)
     ];

but problem still exists, so I guess as hab25 said, that's something else then..

20:47:20
15 Oct 2022
@hexagonk:halogen.cityhexagonkI've updated the issue I mentioned above; located an old working `doomemacs` commit.12:57:47
@hexagonk:halogen.cityhexagonkKeeping track of all the moving parts in a typical NDE install is incredibly fun. And by fun I mean my brain is now broken. But it was really engaging!12:59:21
@ckie:ckie.devmei 🌒&:D13:14:59
16 Oct 2022
@k0kada:matrix.orgk0kada (he/him)
In reply to @hexagonk:halogen.city
I've updated the issue I mentioned above; located an old working `doomemacs` commit.
You're not really supposed to override the doom-emacs inputs
22:06:32
@k0kada:matrix.orgk0kada (he/him)But your work is still useful22:06:39
@k0kada:matrix.orgk0kada (he/him)Going to pin your commit or at least something around it (I think I can get a few newer commits if I change the patches)22:07:04
@k0kada:matrix.orgk0kada (he/him) At least we can unbreak the CI, at least until either ckie (they/them) or me have some more time to investigate how to keep track with upstream 22:07:45
@hexagonk:halogen.cityhexagonkIs there anything I can do to help with triage/tracking of upstream? Basically at the moment I'm doing incredibly stupid things like pinning upstream to bisect what breaks things, but I'd be happy to contribute if there's work to be done.23:34:54
17 Oct 2022
@hexagonk:halogen.cityhexagonkIn the interim I'm going to punch my brain a few times until I start to understand the moving pieces a little bit better. Would love to get a better sense of how/when best to integrate upstream changes to help out with tracking upstream.00:13:49
@ckie:ckie.devmei 🌒& hexagonk: the blocker is this PR failing. the overall flow is config -> doom init -> collect package names -> stick them all in one drv (+elc) -> bundle user config + packages + emacs into a drv 07:15:24
@ckie:ckie.devmei 🌒&which is wrong since packages have versions, not just names, but hooking into straight well enough for vcs info and all of that was not fun07:16:12
@ckie:ckie.devmei 🌒&but anyway this requires a gazillion patches which are not fun to write or maintain07:17:00
@ckie:ckie.devmei 🌒& * but anyway this [sometimes] requires a gazillion patches which are not fun to write or maintain07:17:29
@ckie:ckie.devmei 🌒&current blocker is figuring out how to get doom to actually give the full call trace so its debuggable07:18:11

Show newer messages


Back to Room ListRoom Version: 9