I definitely notice an EDR tax on macOS generally, but I haven't noticed Emacs having issues specifically. It's usually certain I/O operations like Git or tarball extraction that become slow.
1,888 karma · joined October 30, 2013
https://matthewbauer.us/
[ my public key: https://keybase.io/matthewbauer; my proof: https://keybase.io/matthewbauer/sigs/Dqhg8uy67zik_x6jYvk541dbJtMDvZAG8V_RcLSoQyw ]
I definitely notice an EDR tax on macOS generally, but I haven't noticed Emacs having issues specifically. It's usually certain I/O operations like Git or tarball extraction that become slow.
* correcting myself, some zip codes do cross state lines
I like that agent-shell just uses comint instead of a full vterm, but I find myself missing a deeper integration with claude that claude-code-ide has. Like with claude-code-ide you can define custom MCP tools that run Emacs commands.
Package maintainers often think in terms of constraints like I need a 1.0.0 <= pkg1 < 2.0.0 and a 2.5.0 <= pkg2 < 3.0.0. This tends to make total sense in the micro context of a single package but always falls apart IMO in the macro context. The problem is:
- constraints are not always right (say pkg1==1.9.0 actually breaks things)
- constraints of each dependency combined ends up giving very little degrees of freedom in constraint solving, so that you can’t in fact just take any pkg1 and use it
- even if you can use a given version, your package may have a hidden dependency on one if pkg1’s dependencies, that is only apparent once you start changing pkg1’s version
Constraint solving is really difficult and while it’s a cool idea, I think Nixpkgs takes the right approach in mostly avoiding it. If you want a given version of a package, you are forced to take the whole package set with you. So while you can’t say take a version of pkg1 from 2015 and use it with a version of pkg2 from 2025, you can just take the whole 2015 Nixpkgs and get pkg1 & pkg2 from 2015.
Debit cards a pretty common example of this. I believe you can only have ASCII in the cardholder name field.
I still think this survey doesn't make sense, or at least something is lost in transactional.
Postgres doesn’t automatically create indexes - I bet the others have some implicit index on organization_id, created_at. Otherwise they would be giving bad results in other cases. I don’t see why you can’t just make that index in postgres.