Emacs is certainly capable of speedy editing; i don't mean to imply otherwise. But there isn't much explanation as to why emacs does things the way it does even if it makes the experience shittier.
There is just one explanation. The people who develop it like it this way and unless you want to pitch in, your very vague complaints does not really matter.
You’re maybe trolling. But what exactly is slow? Or are you a superhuman typing 400 words a minute? Emacs have never crashed on me (I use it daily) and there are things you just can’t speed up. Multithreading just sidesteps the problem while introducing its own can of worms. The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
> Multithreading just sidesteps the problem while introducing its own can of worms.
In the meantime we're all stuck waiting for package downloads. I don't know the specifics about why emacs can't move to a concurrent model but it's embarrassing at this point
> The current async facilities are fine by me (I don’t use any auto* things, so YMMV).
Yes, it is clear the people who maintain emacs are fine with it. This is why using emacs in 2026 is so shitty.
> In the meantime we're all stuck waiting for package downloads.
I use Elpaca instead of the built-in package manager, which is better designed (declarative package specification) and fully asynchronous. The UI is also more thoughtful, with more granular search-as-you-type capability and easy git commit reviews of pending package updates.
package.el is catching up to Elpaca in features, but async installs/updates is not one of them.