Sender | Message | Time |
---|---|---|
16 Dec 2024 | ||
16:24:37 | ||
Hi, is anyone else running into this issue ? https://github.com/nix-community/emacs-overlay/issues/455 | 16:25:13 | |
In reply to @drishal:matrix.orgemm,what is your nixpkgs channel/commit? | 16:38:05 | |
on nixpkgs I'm on the latest github:nixos/nixpkgs/nixos-unstable/ | 16:53:43 | |
and using the latest github:nix-community/emacs-overlay/ | 16:53:53 | |
anyways this workaround mentioned worked
| 16:57:47 | |
* anyways this workaround mentioned worked
| 16:58:03 | |
17 Dec 2024 | ||
01:11:06 | ||
On nixos, with home-manager f99eace7c (~Feb 2 | 01:11:47 | |
* Back in Feb I set up emacs-overlay with home-manager and got a working config. Now I want to update, but any version bump of either emacs-overlay or home-manager that I try causes the build to fail, most often like this
| 01:13:39 | |
is that expected? am I trying to use emacs-overlay wrong? I see the emacs-overlay just says to grab a random revision of master and put it in your configuration.nix but I'd rather manage emacs with home-manager and my system is managed with flakes, not configuration.nix, anyway | 01:14:31 | |
nongnuDevelPackages was added recently-ish and requires a newer nixpkgs | 01:24:44 | |
In reply to @jean-paul.:matrix.orgthis error says emacs-overlay needs a newer nixpkgs | 01:25:15 | |
@adis:blad.is Currently, naively overriding src and version of Emacs leads to wrong default values of withFoo flags. What is your opinion on a fix? Is it worth the effort? | 01:31:14 | |
https://github.com/nix-community/emacs-overlay/pull/456 | 01:31:16 | |
In reply to @me:linj.techI don't think there is anything we can realistically do | 01:33:48 | |
In reply to @adis:blad.isI have two fixes in mind. An ad-hoc one is to add version to parameters like withFoo flags. Another one is to put withFoo flags into the derivation and then their default values can reference finalAttrs. | 01:37:30 | |
In reply to @me:linj.techYou can do that, but it would make Emacs a very special snowflake in the nixpkgs ecosystem | 01:42:49 | |
In reply to @me:linj.tech* You can do that (finalAttrs), but it would make Emacs a very special snowflake in the nixpkgs ecosystem | 01:43:18 | |
yeah, I agree and that's why I do not think both fixes😅 | 01:43:33 | |
* | 01:43:45 | |
Another cleaner option is to expose the emacs derivation factory function, and not do overriding but creating new derivations from scratch | 01:44:23 | |
sounds good | 01:45:29 | |
linj: Thanks, updated nixpkgs and it built. | 01:53:06 | |
Sad, new emacs lsp is just as broken as old emacs lsp :( | 01:56:24 | |
In reply to @adis:blad.isBtw, kinda related https://github.com/NixOS/nixpkgs/issues/227327 | 01:59:23 | |
* .override idiom one day | 01:59:55 | |
When overriding Emacs, I think both using a factory function and using (emacs.override { version = "...", }).overrideAttrs { src = ... } (after adding version to parameters) are special. I do not think one is better than another. | 02:58:46 | |
* When overriding Emacs, both using a factory function and using (emacs.override { version = "...", }).overrideAttrs { src = ... } (after adding version to parameters) are special. I do not think one is better than another. | 02:59:01 | |
In reply to @me:linj.techI wasn't specifically talking about getting rid of it for emacs, but altogether :) | 03:58:17 |