<snape>i want to talk today to avoid thinking about the things that i try to do and that don't work
<snape>anyway it's personal but I feel like what makes Emacs great is its customizability. And it's only customizable when you can restart it easily to test your new conf. But with EXWM restarting it is a pain (because you lose everything else), so you don't want to customize Emacs and try out things. Conclusion : EXWM makes you love Emacs less
<lechner>yeah, i get that. i usually tweak the variables live and then record them in my init.el, hoping it will work then too
<snape>but when it's stuff like (add-hook 'whatever (lambda () ...))...
<jbnote>Hi, i'm trying to build a parallel script (in the guile repl) to download all of of guix sources. It works, but the stdout access is garbled. Would there be a transparent way in guile to serialize accesses to stdout (at least at the format/display level)? It would probably be sufficient for my needs.
<lilyp>jbnote: you can shadow builtin procedures locally
<lilyp>e.g. (define (format args) (push (delay (apply format args)) some-message-queue))
<apteryx>can help to keep track of recent breakage
<efraim>cbaines: re your question about the guix-commits emails, on my first push of the rust-team branch on october 3rd (I think it was) it hung a long time and said the push failed, but the branch appeared.
<fnat>Thanks apteryx, yeah, the reason I'm asking is because the original repo no longer makes use of Git tags and releases - but of course I can simply use a specific commit (FWIW, I think I also have a preference for tapping to the original repo)
<efraim>lilyp: wait a minute, I think we've had this conversation before, about using esbuild to build the node dependencies for node@18
<fnat>apteryx: yeah, that's actually the case, I think, i.e. no releases and no tags upstream
<fnat>(although I think the author might consider to resume tags/releases if there's a good reason to)
<efraim>probably 8 months ago, you told me esbuild would build individual files but it couldn't really replace calls to npm to build entire packages
<lilyp>fnat: note that melpa distributes unstable snapshots, so to day; they may be fine under circumstances (e.g. no other release for years), but versioning should follow Guix' guidelines rather than MELPA's tagging scheme
<fnat>lilyp: thanks, what do you mean by "Guix' guidelines"?
<lilyp>sorry for the junk, copied directly from the emacs buffer without filtering
<fnat>hey that's alright - thanks for the pointer!
<fnat>ok, I'll see if the project author might be willing to make an upstream (non-Melpa) release; if not, I'll still get the code from upstream by specifying a commit (a more recent commit of what's currently in Guix)
<pastor>Hello. I would like to answer to a mail I got from a patch. I usually use `git send-email` but I don't think using the --in-reply-to is comfortable. How do you guys would answer? I would like to use notmuch or mu4e
<pastor>Can I paste the output of a magit formated patch?
<Rovanion>IIRC you can paste the output of git format-patch at least. But it was long ago I did this.
<rekado>pastor: if you don’t want to use “git send-email” please attach the output of “git format-patch”
<mirai>whereiseveryone: sure, but then the same can be said just about any package and can you imagine the wasted effort of replicating the same package definition?
<mirai>it also presumes that everyone can either effortlessly package or figure out the workarounds for some package
<mirai>I'll believe this when guix is rid of the substitutions in either phases or snippets & guix-bugs contains no issues about package malfunction
<mirai>You do have a point regarding the shortage of hands in guix though
<whereiseveryone>I just think that the current unbounded project scope of what we package paired with our limited availability from reviewers can be slightly denting on the morale of contributors who are in it for the long run
<mirai>Reviewing patches even by non-committers helps (at the very least it shortens the time to upstream since you can flag the problems early and have revisions issued in a shorter amount of time)
<mirai>(personally) I believe a greater help would be to actually collaborate with upstream to actively reduce patching done from our side
<apteryx>mirai: I have to go afk, but I shall return
<mirai>I might be misremembering the actual snippet (can dig the mails to find it) but the difference boils down to whether you want a build script with a list of hardcoded paths or a have a map procedure in its place
<mirai>all do the “same” thing (the build script is smaller in the later)
<mekeor>what's the difference between rust:cargo and rust-cargo? when to use which? or more generally, is there a tutorial on how to work on rust projects on guix (system)? or does everybody rather use a fhs-emulating, containerized guix-shell for this?
<lilyp>rust:cargo is the tool, rust-cargo is the crate