!SlMumQZnFjwLRjWFbW:nixos.org

Nix + Doom Emacs

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

Load older messages


SenderMessageTime
15 Dec 2022
@ckie:ckie.devckie (they/them) Gavin R: my list 19:04:42
@mon:tchncs.deribosomerocker
In reply to@mon:tchncs.de

Well, hello again! I'm starting to have some time again which is why I'm prograrmming some hobby projects lately, mainly using Idris 2, and I thought to boot up Doom Emacs (i don't yet have enough free time to start working on the documentation PR again unfortrunately, though i see you're making some progress, though somewhat slow. keep going!). For whatever reason, the pictured error below appears when running idris2-mode. But... I do depend on prop-menu in my configuration:

doom-emacs = {
  enable = true;
  doomPrivateDir = ./doom;
  extraPackages = [ pkgs.mu ];
  emacsPackage = pkgs.emacsPgtkNativeComp;
  emacsPackagesOverlay = self: super: {
    idris2-mode = self.trivialBuild {
      pname = "idris2-mode";
      ename = "idris2-mode";
      version = "0.0.0";
      buildInputs = [ self.prop-menu ];
      src = pkgs.fetchFromGitHub {
        owner = "idris-community";
        repo = "idris2-mode";
        rev = "4a3f9cdb1a155da59824e39f0ac78ccf72f2ca97";
        sha256 = "sha256-TxsGaG2fBRWWP9aas59kiNnUVD4ZdNlwwaFbM4+n81c=";
      };
    };
  };
};

any idea what's going wrong?

i've checked the issues and there doesn't seem to be an issue like this, i assume this is just another case of my machine being cursed...
19:49:09
@mon:tchncs.deribosomerockerwell, except my issue, but that issue was solved with this exact piece of code19:51:53
@mon:tchncs.deribosomerocker changed their profile picture.19:53:08
@gavinrogers:matrix.orgGavin R
In reply to @ckie:ckie.dev
Gavin R: my list
cool, thanks. why do you have your latex section commented out?
21:41:01
@ckie:ckie.devckie (they/them)it's 5gb or something and latex errors are annoying as fuck21:41:19
@gavinrogers:matrix.orgGavin Rya i'm thinking about just copy/pasted my org tables from my CV into libreoffice and being done with it lol21:42:04
16 Dec 2022
@mon:tchncs.deribosomerockerWell, I've found nothing to fix it. I assume you guys don't know what's going on too?18:58:58
@ckie:ckie.devckie (they/them) ribosomerocker: you probably want a (package! prop-menu) 22:17:39
17 Dec 2022
@adam:valkor.net@adam:valkor.net left the room.04:30:01
18 Dec 2022
@hab25:matrix.org@hab25:matrix.org

I was having trouble installing (package! hyperbole), due to the following error during the nix-straight build:

       > ERROR: doom-emacs build resulted in files being written in $HOME of the build sandbox.
       > Contents of $HOME:
       > /build/tmp.9YIYoZ1pyj
       > /build/tmp.9YIYoZ1pyj/.hyperb

I solved this by, instead of using package!, adding pkgs.emacsPackages.hyperbole to the programs.doom-emacs.extraPackages list. No issues so far.

AFAIU, all I'm losing here are the configuration options of package! which I don't use and are mostly redundant anyway.

I'm thinking of similarly migrating all of my other package!s as well, as it should greatly simplify and reduce bugs in their installation; they will be built by one package (nix) manager instead of "3" (nix, nix-straight, nix-doom-emacs).

Is this a good idea? ckie (they/them) k0kada (he/him)

10:17:25
@k0kada:matrix.orgk0kada (he/him)
In reply to @hab25:matrix.org

I was having trouble installing (package! hyperbole), due to the following error during the nix-straight build:

       > ERROR: doom-emacs build resulted in files being written in $HOME of the build sandbox.
       > Contents of $HOME:
       > /build/tmp.9YIYoZ1pyj
       > /build/tmp.9YIYoZ1pyj/.hyperb

I solved this by, instead of using package!, adding pkgs.emacsPackages.hyperbole to the programs.doom-emacs.extraPackages list. No issues so far.

AFAIU, all I'm losing here are the configuration options of package! which I don't use and are mostly redundant anyway.

I'm thinking of similarly migrating all of my other package!s as well, as it should greatly simplify and reduce bugs in their installation; they will be built by one package (nix) manager instead of "3" (nix, nix-straight, nix-doom-emacs).

Is this a good idea? ckie (they/them) k0kada (he/him)

I still don't think we should have that $HOME check
10:43:28
@k0kada:matrix.orgk0kada (he/him)
In reply to @hab25:matrix.org

I was having trouble installing (package! hyperbole), due to the following error during the nix-straight build:

       > ERROR: doom-emacs build resulted in files being written in $HOME of the build sandbox.
       > Contents of $HOME:
       > /build/tmp.9YIYoZ1pyj
       > /build/tmp.9YIYoZ1pyj/.hyperb

I solved this by, instead of using package!, adding pkgs.emacsPackages.hyperbole to the programs.doom-emacs.extraPackages list. No issues so far.

AFAIU, all I'm losing here are the configuration options of package! which I don't use and are mostly redundant anyway.

I'm thinking of similarly migrating all of my other package!s as well, as it should greatly simplify and reduce bugs in their installation; they will be built by one package (nix) manager instead of "3" (nix, nix-straight, nix-doom-emacs).

Is this a good idea? ckie (they/them) k0kada (he/him)

* I still think we shouldn't have that $HOME check
10:43:38
@k0kada:matrix.orgk0kada (he/him) It does seem this is a legitimate case of a deps just building something and leaving dirty at the simulated $HOME we have 10:44:06
@hab25:matrix.org@hab25:matrix.orgI think it's a useful check, avoids hard to debug problems in the illegitimate cases. But what about directing users to prefer using extraPackages instead of `(package!)`, as I described?11:09:26
@k0kada:matrix.orgk0kada (he/him)
In reply to @hab25:matrix.org
I think it's a useful check, avoids hard to debug problems in the illegitimate cases. But what about directing users to prefer using extraPackages instead of `(package!)`, as I described?
It is not in this particular case
13:47:16
@k0kada:matrix.orgk0kada (he/him)

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with NDE own code checks

13:48:00
@k0kada:matrix.orgk0kada (he/him) *

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with NDE own code

13:48:06
@k0kada:matrix.orgk0kada (he/him) *

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with doom-emacs own code

13:48:56
@hab25:matrix.org@hab25:matrix.org
In reply to @k0kada:matrix.org

But what about directing users to prefer using extraPackages instead of (package!), as I described?

A really bad idea because it will cause issues with doom-emacs own code

Thanks! Do you have a specific issue in mind?
14:03:54
@k0kada:matrix.orgk0kada (he/him)No, but doom-emacs code is complex enough that I can imagine a few hard to debug issues to happen because you're not using the proper way to load a dependency14:05:50
@k0kada:matrix.orgk0kada (he/him)I remember having issues using the wrong way to load a dependency in doom-emacs itself14:06:16
@k0kada:matrix.orgk0kada (he/him)This was before using NDE14:06:32
@k0kada:matrix.orgk0kada (he/him)Anyway, do what you want, but I wouldn't recommend14:06:47
@k0kada:matrix.orgk0kada (he/him) * Anyway, do what you want, but I wouldn't recommend it14:06:52
@k0kada:matrix.orgk0kada (he/him)There is a chance we already do this for NDE itself though, if yes forget what I said14:07:15
@k0kada:matrix.orgk0kada (he/him) But only ckie (they/them) can answer this question 14:07:25
@hab25:matrix.org@hab25:matrix.org
In reply to @k0kada:matrix.org
No, but doom-emacs code is complex enough that I can imagine a few hard to debug issues to happen because you're not using the proper way to load a dependency
True
14:07:37
@hab25:matrix.org@hab25:matrix.orgOk, thanks again!14:07:42
@k0kada:matrix.orgk0kada (he/him)One possibly issue I can think right now is that maybe the deps will not be natively compiled14:08:51

Show newer messages


Back to Room ListRoom Version: 9