why does its nix build work locally but fail in ci
this is the exact thing nix promised to prevent
how does one untangle emacs org-roam deterministically
@sophie if it's comfortable with Rust, I have a little project (pgpgpg) that does almost that. It's not fully deterministic, because it tangles out in the order it finds the org files, but... that should be fixable with a .collect() and a .sort().
If it considers such a third-party tool acceptable, and Rust's fine, I'll go and make it sort the files, so untangling should become deterministic.
@algernon@come-from.mad-scientist.club well given that it is specifically doing this to patch nam-shub of enki and doesn't really touch emacs at all outside of this it's not really that important, but thanks! it is now just adding a new .org file with another browser exception regex to the repo in the nix build (and then patches a few other things that don't have multiple snippets targeting it)
@sophie I had a sneaking suspicion this'd be about NSoE. Few are mad/cruel1 enough to have emacs and org as a dependency. Sorry about that!
I've made a note to have a look at its NSoE patch(es), and see if I can add them to NSoE upstream next time I have some iocaine-time.
FWIW, you can do something like:
checks {
custom-agents {
allow "com.apple.WebKit.Networking/"
}
}
In the NSoE config, and then it will allow that particular agent through. It doesn't do regex, but maybe that bit of the user agent string is rare enough to not need a regex.
Choose one at its leisure. ↩︎
@algernon@come-from.mad-scientist.club it is not exactly in a position to talk given just how much stuff it hacks into its nix config(s); mad/cruel both apply. sadly it does most likely require a regex here because just allowing this single part would not be restrictive enough and now that it has managed to shine a little more light into the madness that is nsoe it's fine like this