| 7 Sep 2023 |
 mei 🌒& | so i usually eval at point in my org config | 13:49:10 |
 JoelMcCracken | one thing about working on nde directly now is that I can run the check thing to see how its working | 13:49:22 |
| mei 🌒& | a friend who wasn't on Nix yet at the time could just M-x package-install and that was like. wow | 13:51:06 |
| mei 🌒& | like i went "oh you should get $X" and they just ran a few things in emacs and got the package | 13:51:23 |
| mei 🌒& | even with vanilla doom that'd be what, a doom sync and restart | 13:51:53 |
| JoelMcCracken | weljl you can i think run M-x doom sync | 13:53:13 |
| mei 🌒& | there's hints of a mainframe ideology in there though; what happens with a few emacsen on different machines | 13:53:20 |
| mei 🌒& | * there's hints of a mainframe ideology in there though; what happens with a few emacsen on different machines? | 13:53:23 |
| JoelMcCracken | sure | 13:54:02 |
| mei 🌒& | * there's hints of a mainframe ideology in there though; what happens with a few emacsen on different machines? | 13:54:29 |
| mei 🌒& | if we had a imperative2nix that'd be really neat | 13:54:50 |
| JoelMcCracken | for sure | 13:54:58 |
| JoelMcCracken | like somehow a way to generate an overlay from the current running doom | 13:55:22 |
| mei 🌒& | what's actually missing for that? what if we put a Nix in the doom | 13:55:28 |
| mei 🌒& | yea | 13:55:29 |
| mei 🌒& | like nix-shell -p but doom calls it from inside its package manager | 13:55:44 |
| mei 🌒& | see: [RFC 0040] "Ret-cont" recursive Nix | 13:57:09 |
| mei 🌒& | vaguely. not sure if that's precisely the right one | 13:57:45 |
| mei 🌒& | yeah this isn't the right one | 14:00:01 |
| mei 🌒& | I think I was thinking of [RFC 0092] Computed derivations but it's been >a year, need to reread | 14:02:38 |
| JoelMcCracken | yeah i don't know | 14:03:33 |
| JoelMcCracken | i imagine it would work like:
- a user picks a package to install from a list
- nix installs it
- emacs loads it within the running process
| 14:05:37 |
| mei 🌒& | mhm, it's essentially tearing out the parts of straight&emacs that do network I/O into their own emacs, running inside a nix build | 14:06:42 |
| mei 🌒& | which works happily for the top-level imperative emacs usecase (editing your config before rebuilding) but you want to have all of these prefetched in the build process once you're ready to deploy it to your 'prod' machine | 14:07:22 |
| mei 🌒& | recursive nix isn't actually a hard dependency-- we can crudely and inefficiently emulate it, but it would make this much more streamlined since it would run through approximately the same codepath in both imperative/Nix sandbox | 14:08:44 |
| mei 🌒& | * recursive nix isn't actually a hard dependency-- we can crudely and inefficiently emulate it, but it would make this much more streamlined since it would run through approximately the same codepath in both the imperative/Nix sandbox usecases | 14:08:49 |
| JoelMcCracken | yeah | 14:08:55 |
| JoelMcCracken | well it depends, what you mean specifically by recursive nix i guess | 14:09:27 |
| mei 🌒& | what do you mean by "nix installs it" though? installs it where. i'd think nix gives some store paths or an elisp payload and emacs evals it into the running process | 14:09:42 |
| mei 🌒& | like this at runtime but also for the elisp path variable | 14:10:15 |
